56k Flex Notes for Rockwell chipset

These notes are loosely based on empirical evidence and the documentation provided on the Rockwell 56kFlex modem chipset. The original PDF documents for the codec and datapump were once available on the Rockwell web site, but were removed when Conexant took them over. The closest equivalent documentation of the generic Hayes command set manual is now on the modemsite.com and mirrored at 808hi.com Be warned that these files are fairly big and they are not easy reading. The original files were intended for electronics designers working with the chipset and AFAIK are no longer available publicly. The URL's change from time to time so drop me a line if links are broken.

There is also a great deal of useful information in Tez Boyes Demon Tech Modems FAQ which should be definitely be consulted for general fast modem advice before considering any of the more risky tuning tweaks.

You should take everything here with a pinch of salt, but it is believed to be accurate, and when I have time I will add new data to the tables. Don't believe everything you read, but I hope these notes will help tune your system, and that feedback will allow me to tune mine better. My BT phone line is probably "average" for the UK supporting stable 46000 and some 48000 connects. In wet weather things can degrade to 42000.

Test files - there are a set of test files on ftp.demon.co.uk which can be downloaded to determine various modem/hardware quirks and problems. They are as follows with best speeds seen for 48000 int/ext modems. I have a Hayes Accura external 56k 5760GB and a Pace internal 56k which have been extensively tested.

The actual speed you can get on a given phone line depends critically on the physical quality of the copper and connections between you and the exchange, or between you and the cable box on a cable service. Here are some typical performance figures for ftping various test files of varying compressibility from Demon at 48000.

Tests were done on a PII using KA9Q and nominal 115200 baud rate. It is clear that the internal modem fakes the serial port as it achieves speeds more consistent with 230400 baud. Unless you are in the habit of downloading large files of nulls or boring repetitive material the difference is academic as neither max out at 115k2 on material which has real data content. The latest V.90 speeds on the same line show that for newsheaders and many Web pages the 115k2 baud rate will be a limiting factor to throughput for RX speeds above 50000.

The numbers here are for a 48000 K56Flex connection with the Pace internal (original 1.02 firmware) and a 44000 connection with the Hayes external running the latest 14/1/98 5670PP 1.120 v14 firmware and connecting to Demon's Ascend firmware 2.1.0 (gold). Values in brackets are estimates for external at 48000.The V.90 numbers are for a 50667 connection with the Pace internal (2.100 firmware). I usually get 49333 or 50667 V.90 connections. V.90 performance is faster than K56Flex and seems to be less likely to drop the line spontaneously than K56Flex. I now use V.90 as my first choice. I have added a column for the best I have been able to achieve using the Pace on a V34+ 33600 connection for comparison.

It appears that the internal modem has a slight edge in performance of about 10% over an external modem running over a real serial link. This may be a worthwhile advantage provided that the internal modem does not crash your computer when it drops connections. I am not a fan of internal modems as I prefer to see real LEDs flickering as reassurance something is going on, but I mainly use the Pace internal modem despite this prejudice. This document results from my notes on tuning my own system for fastest upload and download.

One big surprise for me in the above was that base64 encoded binaries defeat the modem datapump compression algorithm. All base64 files are have the top two bits of every byte the same, and yet the throughput was typical of a pure incompressible binary. I am very surprised by this counter intuitive result.

When a 56k Flex call is established after determining that V.8 is possible the client and server modems take turns to send chirp test signals which sound like Zebedee down the line to calibrate the response and echo cancellation. The result of this test gives a number called appropriately the Eye Quality Monitor or EQM which then determines the initial connect rate according to the following table:

I only have significant data for connections between 42000 and 46000 and my own experience is limited mainly to connections at 46000 using PPP. I find it switches to 48000 slightly earlier than the table above suggests, and this is probably due to refinements in the modems which are not reflected in the datasheets. In general throughput on fullfile should be roughly predictable as Rxrate/K. And I find that for PPP K=9 and am told that for SLIP K=10 very approximately. YMMV. Hard experimental speeds and EQM's for extremely high quality lines would be nice to add. The table above is derived from a table given in Rockwells datapump design information datasheet 1126r1.PDF. Unfortunately it is no longer available. It also contains one of the clearer accounts of how EQM is computed for those that are interested. For the purposes of tuning a system it suffices to know that big is bad and small is beautiful.

The first table is used to determine the initial connect speed which is reported, but after the connection has finished it is possible to extract some statistics from the modem by sending the AT&V1 command to it. The initial connection speed is a reasonable guide to your lines performance, although I suspect the modems err a bit on the optimistic side and drop back by 2000 after only a few minutes of connection.

Note also that "line quality" is not simply related to data rate. A line quality of XX at a higher rate indicates a better quality of line. The EQM is a much better if slightly noisy guide to your true line quality. The question of how "Line Quality" relates to EQM is interesting and illustrated in the graph below.

I have shown the graph schematically over a typical range of TX rates from 38000 to 50000. Note that for each TX rate the Line Quality varies over a range, and there is some overlap with adjacent speeds. The modem will fall forward if it finds the Line Quality value lower than the limit for the present speed, and fall back if it finds the Line Quality is too high for the present speed.Note that "Line Quality" is a poor choice of name as big numbers are worse! Line Corruption would be a better description.

It should be obvious from the graph that saying "my Line Quality is 10" does not shed much light on anything as it could be a poor 44k or a really solid 50k connection and still return that numeric quality value.

The overlap of the ranges is necessary to provide hysteresis and avoid the modems hunting between two adjacent speeds if the Line Quality happens to be borderline. The small arrows show the points where fall forward and fallback would trigger for a TX rate 46000 connection. I suspect it can still happen though and may be responsible for some of the modem retraining faults which sometimes lead to dropped lines. The numbers shown are broadly representative but should be considered as a qualitative guide to modem performance.

Different firmware seems to allocate slightly different ranges of EQM to each speed band, and also different numerical values to the averaged "Line Quality" parameter. The latest V.90 modems seem to give numbers for line quality which are roughly 2x larger than those for a K56Flex modem under the same conditions.

My own phone line is imperfect and living more than ten miles from the exchange does not help the signal strength or quality. This seems to affect the transmit rate when using 56kFlex. Typically:

Most of the time there is a loss of upload speed when using 56kFlex and for sending very large files it may be advantageous to force connection using V34+ Historically I have done this by dialling into a modem block which does not support 56k, but now have Z0 and Z1 set to be 56k and V34+ connections respectively.

You can force a V34+ connection by adding the incantation "+MS=11,1,2400,33600,1,0" to the modem initialisation string. Or saving a suitable V34 profile in Z1. Check modem manuals for how to do this.

There seems to be an interesting distinction between the rate renegotiation and full retrain which may explain some of the things which happen and are reported incorrectly as "network death".

The most frequent connect statistics for &V1 that I see are

The most common result by far is the first one (>90%), with small variations of EQM and a few connects at TX 28800. All of the others occur after a speed renegotiation has occurred which is noticable by data transfer stalling for a few seconds and the last two of these 63/87 & 20/21 are failures. Sometimes the modem disconnects after trying to retrain 3 times, or failing to transmit a data block after ??? attempts.

Is it possible to make a 56k Flex connection run faster? The answer is a qualified yes. The modem is supposed to choose the best combination of RX & TX speeds it can manage given the prevailing line conditions. Which means that for big uploads V34+ remains the method of choice.

The tweak for tuning 56k Flex relies on adjusting your modems S91 register which alters TX line attenuation and can be used to tune throughput and alter the balance between up and download speeds. This only seems to work for some modems and you may or may not be lucky.

So for my system I can improve the TX rate from 26400 to 28800 by changing the S91 value from the default 10 to 7 without compromising the incoming RX rate. It works very well on my Pace internal, but reports show that this trick does not work with all Rockwell modems, and some seem to have the S91 default hardwired. If this is the case you will not see any changes in the &V1 statistics when you adjust the value in S91.

I have also heard of people being able to boost their RX rate by increasing the value in S91 (cf the step in rates between 00 and 04 on mine. S91 tweaking is also mentioned in the demon.tech.modems FAQ. Changing the value in S91 too much may annoy your telecom company (one reason perhaps why some modems do not permit it).

If you suffer problems with rate renegotiation or retraining it may be worth forcing a slightly slower connection and disabling either or both of fall forward/fall back and automatic retrain. It has worked for me in the past.

I have also been playing with V.90 on the Hayes external and the Pace internal and can report mixed success. The Hayes Asia Pacific code appears to work well for me, and better after setting proper UK defaults. The Pace internal by comparison is pretty hopeless at connecting to the Demon Ascends and fails to get past initial training and speed negotiations on about 30% of all calls. When it connects it usually gets a 49333 TX rate, which soon drops to 48000 and a 26400 RX rate. I had a few V.90 connects report maximum speeds equal to the theoretical maximum of 56000, although real throughput on file seems very similar to K56Flex running with RX rate of 46000. Other users of Pace internal modems report similar V.90 problems, but their external modems are said to be OK. The results of systematic analysis of my logged dialup connection rates on K56Flex and V90 are summarised.

Mistakes in the above cannot be ruled out and I would welcome corrections, comments, suggestions or additional speed data for K56 Flex and V.90 modems. One other recommendation is that before changing any parameters in your modem or setup you make a full printed record of all the settings. It is too easy to make changes which break things. The information in this note is believed to be accurate, but you use it entirely at your own risk.

These pages are no longer maintained beyond ensuring that the links point to valid URLs.

K56Flex is long gone for most dialup users and I mainly use ISDN or broadband connections now.