DTE<->DCE port speed for Lucent Winmodems
Michail Pappas
DTE<->DCE limited link can also impose an upper limit on data
transfers from DTE<->The Net. In theory, highly compressible data
downloads, can possibly yield data transfer rates in excess of 200
kbps over a serial cable. Franc Zabkar demonstrated this by installing
a modified serial Windows driver, and modifying the Windows registry
to allow for transfers up to 230400 bps. He also indicated that
throughput rates of 20 Kbytes/sec (approximately 160 kbps) were
encountered, which confirms this case.
What happens in the case an internal modem is installed, which does
not contain physically an UART? For example, Lucent Winmodems do not
contain such ICs. In the modem's properties a port speed of 115200 is
indicated, but is not selectable. Is the modem driver communicating
directly with Windows, rendering any "port speed" value needless if
not inapplicable? Just asking these, since I have yet to come by a
20kbytes/sec transfer rate.
My tests with 50kbps+ connections (Zoom
2928L, Lucent winmodem) indicated compressed file transfers in the
5.5kbytes/sec range, while compressible data (e.g. plain text files)
downloaded at around 11.5 kbytes/sec. Note that the latter figure is
approximately equal to 11.5*8=92000 bps which is the "usable" transfer
rate of a 115200 bps serial link, before adding start/stop bits! Is it
a coincidence? Or did I miss the fact that this thing _does_ contain
an UART after all?
--
Michael.-
-------------------------------------------------------------
Remove "no" and "spam" from mail address for an e-mail reply.
Geoffrey Welsh
<nompa...@intracom.gr> wrote:
>[...] In theory, highly compressible data downloads, can possibly
>yield data transfer rates in excess of 200 kbps over a serial cable.
Such data are rare in the real world (e.g. uncompressed database dumps) and
you're not going to get that kind of throughput on anything that is
commonly transferred (including text.) Compressed stuff (including .GIF
and .JPG images) will get zero to negligible compression. Web surfing
interleaves the two, usually with image sizes far outweighing text, so you
get plenty of room for good compression on the text.
Welsh's law: the _information_ transfer rate of a compressed channel is
approximately constant.
Corollary: the only way to get extremely high throughput via extremely high
compression is to send data so repetitive that it contains practically no
useful information and is therefore not worth sending at any speed.
>What happens in the case an internal modem is installed, which does
>not contain physically an UART? For example, Lucent Winmodems do not
>contain such ICs. In the modem's properties a port speed of 115200 is
>indicated, but is not selectable. Is the modem driver communicating
>directly with Windows, rendering any "port speed" value needless if
>not inapplicable? Just asking these, since I have yet to come by a
>20kbytes/sec transfer rate.
Pretty much. The concept of DTE and DCE are irrelevant in controllerless
modems, as the part of the modem to which one used to send data via the
fixed-speed serial port is now implemented in a software driver.
>My tests with 50kbps+ connections (Zoom
>2928L, Lucent winmodem) indicated compressed file transfers in the
>5.5kbytes/sec range, while compressible data (e.g. plain text files)
>downloaded at around 11.5 kbytes/sec. Note that the latter figure is
>approximately equal to 11.5*8=92000 bps which is the "usable" transfer
>rate of a 115200 bps serial link, before adding start/stop bits! Is it
>a coincidence? Or did I miss the fact that this thing _does_ contain
>an UART after all?
Maybe it is just coincidence, but you're forgetting something very
important: your there are many links and the 'speed limit' of a transfer is
the speed of the slowest link. What's on the other side of the modem call?
If it's a simple modem, does it have a UART and, if it's an access server,
does it have some form of limit? What's between it and the source of the
file?
--
Geoffrey Welsh; crs...@inforamp.net; http://home.inforamp.net/~crs0794/
This address is not to be sent bulk mail, nor to be sold or given away. Bill S. 1618 is NOT LAW; it died at the end of the 105th Congress in 1998. Unsolicited bulk mail is spam, no matter what regulations (real or imagined) it complies with! It is IMPOSSIBLE to purchase an opt-in list, as the users on that list did not opt in for YOUR promotions!
Aaron Leonard
~ >2928L, Lucent winmodem) indicated compressed file transfers in the
~ >5.5kbytes/sec range, while compressible data (e.g. plain text files)
~ >downloaded at around 11.5 kbytes/sec. Note that the latter figure is
~ >approximately equal to 11.5*8=92000 bps which is the "usable" transfer
~ >rate of a 115200 bps serial link, before adding start/stop bits! Is it
~ >a coincidence? Or did I miss the fact that this thing _does_ contain
~ >an UART after all?
~ Maybe it is just coincidence, but you're forgetting something very
~ important: your there are many links and the 'speed limit' of a transfer is
~ the speed of the slowest link. What's on the other side of the modem call?
~ If it's a simple modem, does it have a UART and, if it's an access server,
~ does it have some form of limit? What's between it and the source of the
~ file?
That's a spot-on comment. Our old AS5200 Microcom 56K modems were implemented
via physical UARTS (actually "quadarts") which were indeed limited to 115.2k
async (hence about 92k payload.) Our more recent digital modems - the MICA
modems found in the AS5300, and the NextPort CSMV/6 in our latest NASes -
use direct bus connections and so don't have that limit.
In practice, MICA throughput is limited to around 200k. I've measured an
actual download rate of 170k from MICA to an LT winmodem. NextPorts have
been measured at rates as high as 400k (using V.44), although of course you
need to be moving some unusually compressible data to achieve that.
Aaron
Michail Pappas
| On 06 Aug 2001 16:15:22 +0300, in comp.dcom.modems, Michail Pappas
| <nompa...@intracom.gr> wrote:
|
| >[...] In theory, highly compressible data downloads, can possibly
| >yield data transfer rates in excess of 200 kbps over a serial cable.
|
| Such data are rare in the real world (e.g. uncompressed database dumps) and
| you're not going to get that kind of throughput on anything that is
| commonly transferred (including text.) Compressed stuff (including .GIF
| and .JPG images) will get zero to negligible compression. Web surfing
| interleaves the two, usually with image sizes far outweighing text, so you
| get plenty of room for good compression on the text.
|
| Welsh's law: the _information_ transfer rate of a compressed channel is
| approximately constant.
|
| Corollary: the only way to get extremely high throughput via extremely high
| compression is to send data so repetitive that it contains practically no
| useful information and is therefore not worth sending at any speed.
Totally agree. I didn't want to include these first paragraphs in the
original post, yet I couldn't think of a better introduction to my
message's main subject.
|
| >What happens in the case an internal modem is installed, which does
| >not contain physically an UART? For example, Lucent Winmodems do not
| >contain such ICs. In the modem's properties a port speed of 115200 is
| >indicated, but is not selectable. Is the modem driver communicating
| >directly with Windows, rendering any "port speed" value needless if
| >not inapplicable? Just asking these, since I have yet to come by a
| >20kbytes/sec transfer rate.
|
| Pretty much. The concept of DTE and DCE are irrelevant in controllerless
| modems, as the part of the modem to which one used to send data via the
| fixed-speed serial port is now implemented in a software driver.
|
| >My tests with 50kbps+ connections (Zoom
| >2928L, Lucent winmodem) indicated compressed file transfers in the
| >5.5kbytes/sec range, while compressible data (e.g. plain text files)
| >downloaded at around 11.5 kbytes/sec. Note that the latter figure is
| >approximately equal to 11.5*8=92000 bps which is the "usable" transfer
| >rate of a 115200 bps serial link, before adding start/stop bits! Is it
| >a coincidence? Or did I miss the fact that this thing _does_ contain
| >an UART after all?
|
| Maybe it is just coincidence, but you're forgetting something very
| important: your there are many links and the 'speed limit' of a transfer is
| the speed of the slowest link. What's on the other side of the modem call?
| If it's a simple modem, does it have a UART and, if it's an access server,
| does it have some form of limit? What's between it and the source of the
| file?
|
I was aware of the capabilities of
access servers to limit bandwidth available to dial-up users by command,
but the fact that UARTs may be used on the access server certainly did
not cross my mind. Always thought that some sort of data/control bus
would exist between the DSPs used and the actual logic that routes
information back and forth.
Michail Pappas
There goes the server-UART-limited scenario... One of my ISPs is using
Cisco with MICA modems (the other one is using Lucent Ascend) so there
shouldn't be any 92k payload limitation. This is a somewhat strange
situation since both logic (no UART on LT winmodems, hence no
DTE<->DCE limit) as well as your experiences with LT throughput on
MICAs contradict my own experiences (a 92kbps effective
throughput). Perhaps a problem exists on my own setup then.
Franc Zabkar
put finger to keyboard and composed:
>In a recent lengthy discussion it was pointed out that a 115200 bps
>DTE<->DCE limited link can also impose an upper limit on data
>transfers from DTE<->The Net. In theory, highly compressible data
>downloads, can possibly yield data transfer rates in excess of 200
>kbps over a serial cable. Franc Zabkar demonstrated this by installing
>a modified serial Windows driver, and modifying the Windows registry
>to allow for transfers up to 230400 bps. He also indicated that
>throughput rates of 20 Kbytes/sec (approximately 160 kbps) were
>encountered, which confirms this case.
>
>What happens in the case an internal modem is installed, which does
>not contain physically an UART?
My "hard" Rockwell internal modem does not contain a real UART.
Instead the UART is emulated by the modem's chipset. The "port speed"
is also emulated, probably to give the internal modem the same look
and feel as an external. It appears that the modem's controller
inserts artificial pauses between each successive character to
correspond to the selected DTE speed and word format. For example, if
configured for 8N1 the controller waits 10 bit times before
transferring the next byte.
The UART emulation may not be perfect. For example, if I select a DTE
rate of 110bps, comms apps will report that the UART's baud rate
registers are correctly set for 110bps, but the modem will ignore this
unsupported setting and revert to a DTE rate of 57600bps. In fact the
modem will respond with "CONNECT 57600" if configured to report the
DTE rate, and if the DTE rate has been set to some inappropriate
value.
>For example, Lucent Winmodems do not
>contain such ICs. In the modem's properties a port speed of 115200 is
>indicated, but is not selectable. Is the modem driver communicating
>directly with Windows, rendering any "port speed" value needless if
>not inapplicable? Just asking these, since I have yet to come by a
>20kbytes/sec transfer rate.
I've dumped various Lucent VXD and SYS files (ver 5.75) and found
references to various DTE rates, including 230400. While I have no
experience with Lucent controllerless modems, it would appear that you
should be able to vary the port rate.
>My tests with 50kbps+ connections (Zoom
>2928L, Lucent winmodem) indicated compressed file transfers in the
>5.5kbytes/sec range, while compressible data (e.g. plain text files)
>downloaded at around 11.5 kbytes/sec. Note that the latter figure is
>approximately equal to 11.5*8=92000 bps which is the "usable" transfer
>rate of a 115200 bps serial link, before adding start/stop bits! Is it
>a coincidence? Or did I miss the fact that this thing _does_ contain
>an UART after all?
The concept of a "serial link" for a purpose built internal modem
makes no sense. This is because the DSP has already converted the
incoming serial data to parallel format. The modem's controller then
simply transfers this parallel data across the ISA or PCI bus. In fact
the Conexant docs refer to the external and internal versions of their
chipsets and firmware as either "serial" or "parallel".
AFAIK, the only modern internal modem that uses a genuine UART is the
Courier, which probably leverages an existing external design by
stripping off the power supply and RS232 parts, and tacking on a UART
and COM port logic. IMO this is an inefficient design because it
involves unnecessary parallel-to-serial and serial-to-parallel
conversions. Furthermore, a real UART would be constrained by its
rather small FIFO buffer which could contribute to serial overrun
problems.
-- Franc Zabkar
Please remove one 'g' from my address when replying by email.
Franc Zabkar
<crs...@inforamp.net> put finger to keyboard and composed:
In my case the speed limits are determined by my modem's UART
emulation algorithm. While mine is an internal hardware Rockwelloid, I
suspect that the LT modem would be artificially limited in a similar
manner.
For example, if I limit my internal modem to a DTE rate of 115200bps,
I find that the max download rate is about 11.5K bytes/sec. If I then
use a port speed of 230400bps, I can measure download rates of 22Kbps.
To saturate the DTE interface I email a highly compressible file to
myself. This file consists of the letter "a" repeated one million
times.
Michail Pappas
And that is exactly what I am trying to find here.
| For example, if I limit my internal modem to a DTE rate of 115200bps,
| I find that the max download rate is about 11.5K bytes/sec. If I then
| use a port speed of 230400bps, I can measure download rates of 22Kbps.
|
Franc, in your opinion are the changes you implemented in the registry
to change the speed of this virtual port "portable" to other modem
types, or do you feel that they are mainly/solely Rockwell-oriented?
Michail Pappas
| On 06 Aug 2001 16:15:22 +0300, Michail Pappas <nompa...@intracom.gr>
| put finger to keyboard and composed:
|
| >In a recent lengthy discussion it was pointed out that a 115200 bps
| >DTE<->DCE limited link can also impose an upper limit on data
| >transfers from DTE<->The Net. In theory, highly compressible data
| >downloads, can possibly yield data transfer rates in excess of 200
| >kbps over a serial cable. Franc Zabkar demonstrated this by installing
| >a modified serial Windows driver, and modifying the Windows registry
| >to allow for transfers up to 230400 bps. He also indicated that
| >throughput rates of 20 Kbytes/sec (approximately 160 kbps) were
| >encountered, which confirms this case.
| >
| >What happens in the case an internal modem is installed, which does
| >not contain physically an UART?
|
| My "hard" Rockwell internal modem does not contain a real UART.
| Instead the UART is emulated by the modem's chipset. The "port speed"
| is also emulated, probably to give the internal modem the same look
| and feel as an external. It appears that the modem's controller
| inserts artificial pauses between each successive character to
| correspond to the selected DTE speed and word format. For example, if
| configured for 8N1 the controller waits 10 bit times before
| transferring the next byte.
Can't figure why a manufacturer would go the entire route of
implementing a virtual COM port on a _winmodem_ device sitting on a
high-speed bus like PCI. H.324/legacy applications perhaps?
One of the reasons of insisting on internal PCI modems was assuming
that these COM port issues would be a thing of the past. Furthermore,
since rates higher than 115200 _are_ supported from the device driver,
why not ship the driver with a default configuration of say 230400
bps? Significant system resource overhead perhaps?
|
| The UART emulation may not be perfect. For example, if I select a DTE
| rate of 110bps, comms apps will report that the UART's baud rate
| registers are correctly set for 110bps, but the modem will ignore this
| unsupported setting and revert to a DTE rate of 57600bps. In fact the
| modem will respond with "CONNECT 57600" if configured to report the
| DTE rate, and if the DTE rate has been set to some inappropriate
| value.
|
| >For example, Lucent Winmodems do not
| >contain such ICs. In the modem's properties a port speed of 115200 is
| >indicated, but is not selectable. Is the modem driver communicating
| >directly with Windows, rendering any "port speed" value needless if
| >not inapplicable? Just asking these, since I have yet to come by a
| >20kbytes/sec transfer rate.
|
| I've dumped various Lucent VXD and SYS files (ver 5.75) and found
| references to various DTE rates, including 230400. While I have no
| experience with Lucent controllerless modems, it would appear that you
| should be able to vary the port rate.
Just wish Ed Schulz could read this. Granted, the generic Agere/Lucent
winmodem drivers are provided "as is", but his words of wisdom on the
subject would be more than welcome.
Aaron Leonard
from Cisco NASes to an LT winmodem. In test one (MICA), the
effective throughput rate was 178100 bps. In test two (NextPort),
the effective throughput rate was 194962 bps. Therefore, it does
not appear that the LT chipset has any inherent "115200" (92160)
or "23400" (184320) DTE rate limitation.
It may be that PARTICULAR implementations using the LT winmodem
chipset might have limitations.
More details of the test below.
Cheers,
Aaron
---
Client system: IBM ThinkPad T20 (800MHz[?] P3, W2Ksp1)
Client modem: Xircom MPCI WinGlobal 1.98.2
Chipset: LT Apollo 5.93
Server 1: Cisco AS5300 with MICA modems (2.9.1.0 portware)
Server 2: Cisco AS5400 with NextPort CSMV/6 modems (0.6.93.12)
Method: Dial using HyperTerminal PE3. COM port used by HT
was configured for 115200/8N1/hw flowcontrol. Login to IOS exec.
Start HT text file capture. Issue the following commands:
term length 0
show memory
Watch the wallclock. When the command output stops, stop the
capture. Divide the filesize by wallclock seconds.
Test 1 (MICA): connect in V.90 (44000/24000) with LAPM/V.42bis
Result: 2 070 410 bytes in 93s = 178100 bps
Test 2 (NextPort): connect in V.90 (45333/24000) with LAPM/V.42bis
Result: 10 186 764 bytes in 418s = 194962 bps
Bob Starnes
Take a look at http://kronos.v-share.com/~v_laessig/ping.html
See the section - Enabling 230400 Maximum Speed (serial port speed)
--
--- I'm no expert, just trying to help ---
Reply to newsgroup if possible, otherwise
** Please remove "NOSPAM" from my address for email **
Franc Zabkar
I've seen reports from people using similar hacks for other modem
types, so I'm fairly certain they are not specific to a particular
modem brand. I believe the changes merely define the allowable range
of DTE rates that can be accessed by TAPI compliant applications. For
example, the "Properties" value affects the range of port rates
available in the "Maximum speed" box in the DUN connectoid. I suspect
that a TAPI compliant app selects a particular port rate via some kind
of high level function call, and that the serial driver then handles
the specific hardware issues. For a real serial port at COM2, using a
standard 16450/16550 UART, this involves writing a 2-byte baud rate
divisor to the Divisor Latches at IO addresses 2F8 and 2F9. I don't
know what is involved in the case of a virtual UART, though.
To achieve port rates in excess of 115200, some motherboard multi-IO
chips have a clock doubling or quadrupling feature. In these cases the
standard serial driver continues to be used, but the actual port rates
are 2 or 4 times the selected value. For example, to achieve a DTE
rate of 230400bps a multi-io chip could be preprogrammed with a clock
doubling utility, possibly via the autoexec.bat file. A port rate of
115200 would then be selected from within the comms app.
The case of my own internal hardware Rockwelloid seems a bit more
complicated. For speeds up to 115200 the standard serial driver sees a
standard COM port, with real divisor latches at 2F8/2F9. A min divisor
of 1 with a standard UART clock rate of 1.8432MHz produces a max DTE
rate of 1843200 / 16 / 1 = 115200bps. How does the modem achieve a
port rate of 230400bps? I don't know, but I suspect it may be either
via some AT command, or by setting a "reserved" bit in a particular
UART register.
Franc Zabkar
<crs...@inforamp.net> put finger to keyboard and composed:
>Maybe it is just coincidence, but you're forgetting something very
>important: your there are many links and the 'speed limit' of a transfer is
>the speed of the slowest link.
In an attempt to determine whether my ISP's equipment is imposing some
kind of speed limit, I stumbled upon some curious behaviour.
I have a modem at COM2, IRQ9. I set its DTE rate to 115200bps and
emailed a highly compressible file consisting of the letter "a"
repeated ad infinitum. Win95B Sysmon reported an upload speed of
~9KBps and a download rate of 11.5KBps. While the download result was
as expected, I would have thought that the upload should have
saturated the COM port, ie I was expecting an upload speed of
11.5KBps. This result was independent of the serial driver used
(rockser.vxd or serial.vxd), and the same upload limitation was
encountered at a port rate of 230400bps.
The strange thing is that, if I generate interrupts by holding down
the SHIFT key on my keyboard, or by "winding up" my mouse (COM1,
IRQ4), the upload speed climbs to 11.5KBps and stays there!
At a port rate of 230400bps the upload figures are similar
(11-12KBps), but download rates are limited to about 22KBps,
irrespective of whether I'm generating interrupts via the mouse or
keyboard.
Michail Pappas
| Michail Pappas wrote:
| >
| > franc...@dinggoblue.net.au (Franc Zabkar) writes:
| >
[...]
| > | For example, if I limit my internal modem to a DTE rate of 115200bps,
| > | I find that the max download rate is about 11.5K bytes/sec. If I then
| > | use a port speed of 230400bps, I can measure download rates of 22Kbps.
| > |
| >
| > Franc, in your opinion are the changes you implemented in the registry
| > to change the speed of this virtual port "portable" to other modem
| > types, or do you feel that they are mainly/solely Rockwell-oriented?
|
| Take a look at http://kronos.v-share.com/~v_laessig/ping.html
|
| See the section - Enabling 230400 Maximum Speed (serial port speed)
Great info Bob, thanks! I'try to check it tomorrow, since I am in the
middle of a new phone cabling installation, in order to resolve
some modem connect problems.
Michail Pappas
| On 07 Aug 2001 11:36:10 +0300, Michail Pappas <nompa...@intracom.gr>
| put finger to keyboard and composed:
|
| >franc...@dinggoblue.net.au (Franc Zabkar) writes:
| >
[...]
| >| For example, if I limit my internal modem to a DTE rate of 115200bps,
| >| I find that the max download rate is about 11.5K bytes/sec. If I then
| >| use a port speed of 230400bps, I can measure download rates of 22Kbps.
| >|
| >
| >Franc, in your opinion are the changes you implemented in the registry
| >to change the speed of this virtual port "portable" to other modem
| >types, or do you feel that they are mainly/solely Rockwell-oriented?
|
| I've seen reports from people using similar hacks for other modem
| types, so I'm fairly certain they are not specific to a particular
| modem brand. I believe the changes merely define the allowable range
| of DTE rates that can be accessed by TAPI compliant applications. For
| example, the "Properties" value affects the range of port rates
| available in the "Maximum speed" box in the DUN connectoid. I suspect
| that a TAPI compliant app selects a particular port rate via some kind
| of high level function call, and that the serial driver then handles
| the specific hardware issues. For a real serial port at COM2, using a
| standard 16450/16550 UART, this involves writing a 2-byte baud rate
| divisor to the Divisor Latches at IO addresses 2F8 and 2F9. I don't
| know what is involved in the case of a virtual UART, though.
I'll check a registry hack link provided by Bob. Hopefully, I'll have
some positive information to share with you all!
Μιχάλης Παππάς
news:3b703991....@usenet.cisco.com...
| I ran some fresh tests, downloading highly compressible text
| from Cisco NASes to an LT winmodem. In test one (MICA), the
| effective throughput rate was 178100 bps. In test two (NextPort),
| the effective throughput rate was 194962 bps. Therefore, it does
| not appear that the LT chipset has any inherent "115200" (92160)
| or "23400" (184320) DTE rate limitation.
|
| It may be that PARTICULAR implementations using the LT winmodem
| chipset might have limitations.
|
[...]
There is another reason this may happen: my shortsightness! I made a
synthetic file that comprised of approximately 8000 repetitions of a CR/LF
terminated string. The string consisted of 190 repetitions of character zero
("0"). The file can be fetched from http://www.aias.gr/mpap/modemtest.txt
for your own tests.
Results to the same ISP:
V.42bis enabled, PPP Stac LZS disabled: 30.31 kbytes/sec (more than
240kbps)!
(For reference only) V.42bis disabled, PPP Stac LZS enabled: 51.53
kbytes/sec (more than 400 kbps).
No registry modifications whatsoever.
Μιχάλης Παππάς
news:jy8zgvg...@intracom.gr...
| Bob Starnes <rastarn...@hotmail.com> writes:
|
| |
| | Take a look at http://kronos.v-share.com/~v_laessig/ping.html
| |
| | See the section - Enabling 230400 Maximum Speed (serial port speed)
|
| Great info Bob, thanks! I'try to check it tomorrow, since I am in the
| middle of a new phone cabling installation, in order to resolve
| some modem connect problems.
Seems that is not needed for my modem, after all. A lot of responses for an
erreneous posting of mine, that shouldn't happen in the first place (see
response to Leonard in the same thread). Thanks all of you Guys for your
trouble.
Michail Pappas
news:jy8zgvg...@intracom.gr...
| Bob Starnes <rastarn...@hotmail.com> writes:
|
| |
| |
| | See the section - Enabling 230400 Maximum Speed (serial port speed)
|
| Great info Bob, thanks! I'try to check it tomorrow, since I am in the
| middle of a new phone cabling installation, in order to resolve
| some modem connect problems.
Seems that is not needed for my modem, after all. A lot of responses for an
Michail Pappas
news:3b703991....@usenet.cisco.com...
| from Cisco NASes to an LT winmodem. In test one (MICA), the
| effective throughput rate was 178100 bps. In test two (NextPort),
| the effective throughput rate was 194962 bps. Therefore, it does
| not appear that the LT chipset has any inherent "115200" (92160)
| or "23400" (184320) DTE rate limitation.
|
| It may be that PARTICULAR implementations using the LT winmodem
| chipset might have limitations.
|
[...]
There is another reason this may happen: my shortsightness! I made a
synthetic file that comprised of approximately 8000 repetitions of a CR/LF
terminated string. The string consisted of 190 repetitions of character zero
("0"). The file can be fetched from http://www.aias.gr/mpap/modemtest.txt
for your own tests.
Results to the same ISP:
V.42bis enabled, PPP Stac LZS disabled: 30.31 kbytes/sec (more than
240kbps)!
(For reference only) V.42bis disabled, PPP Stac LZS enabled: 51.53
kbytes/sec (more than 400 kbps).
No registry modifications whatsoever.
Michail Pappas
news:9ks7jb$jko$1...@aluminium.acn.gr...
| ("0"). The file can be fetched from http://www.aias.gr/mpap/modemtest.txt
| for your own tests.
Correct URL:
http://users.aias.gr/mpap/modemtest.txt
Franc Zabkar
<nompa...@aias.gr> put finger to keyboard and composed:
>I made a
>synthetic file that comprised of approximately 8000 repetitions of a CR/LF
>terminated string. The string consisted of 190 repetitions of character zero
>("0"). The file can be fetched from http://www.aias.gr/mpap/modemtest.txt
>for your own tests.
Here is an easy way to create a file (zeros.txt) consisting of the
character "0" repeated one million times, without CRLF terminators.
From the DOS prompt type the following:
cd %temp%
debug
-f 0 f423 "0"
-rcx
CX 0000
:f424
-n A
-w
Writing 0F424 bytes
-q
copy /b A+A+A+A B
copy /b /y B+B+B+B A
del B
ren A zeros.txt
Michail Pappas
But you have to have DOS installed :) Just joking!
It was not as difficult as it seems. Just create a single line and
then copy and paste it, copy the resulting two lines and paste them,
etc. For 8192 lines, the copy/paste operation was applied 13 times.
Only thing is that these tests are _too_ synthetic. ITU maintains some
test files used for these purposes, but I am not aware whether these
files are freely available or not.
OT, but I would certainly appreciate your opinion on the following:
thinking of implementing a small Javascript in my web page, that
will accept V.8 CM/JM messages in an octet form (as provided by
Unimodem diagnostics) and produce a human recognisable
result. Do you think that this may prove any useful at all?
Michail Pappas
| OT, but I would certainly appreciate your opinion on the following:
| thinking of implementing a small Javascript in my web page, that
| will accept V.8 CM/JM messages in an octet form (as provided by
| Unimodem diagnostics) and produce a human recognisable
| result. Do you think that this may prove any useful at all?
Franc, Bob and others, you can check this small V.8 octet string parser at
http://users.aias.gr/mpap/v8parser.html
There were some web server problems earlier on, so you could just get back
to me if problems persist. If you have any comments on this, just let me
know.
Franc Zabkar
<nompa...@aias.gr> put finger to keyboard and composed:
>Ο "Michail Pappas" <nompa...@intracom.gr> έγραψε στο μήνυμα
>news:jyu1zhi...@intracom.gr...
>| OT, but I would certainly appreciate your opinion on the following:
>| thinking of implementing a small Javascript in my web page, that
>| will accept V.8 CM/JM messages in an octet form (as provided by
>| Unimodem diagnostics) and produce a human recognisable
>| result. Do you think that this may prove any useful at all?
>
>Franc, Bob and others, you can check this small V.8 octet string parser at
>http://users.aias.gr/mpap/v8parser.html
>
>There were some web server problems earlier on, so you could just get back
>to me if problems persist. If you have any comments on this, just let me
>know.
I found your utility to be very useful with PCtel modems, but not for
my controller based Rockwelloid. This is because the only V.8 data
that are returned by my Rockwell modem consists of octets 13 through
18.
Michail Pappas
news:3b74e4e...@news.dingoblue.net.au...
| On Fri, 10 Aug 2001 18:31:27 +0300, "Michail Pappas"
| <nompa...@aias.gr> put finger to keyboard and composed:
at
| >http://users.aias.gr/mpap/v8parser.html
| >
| >There were some web server problems earlier on, so you could just get
back
| >to me if problems persist. If you have any comments on this, just let me
| >know.
|
| I found your utility to be very useful with PCtel modems, but not for
| my controller based Rockwelloid. This is because the only V.8 data
| that are returned by my Rockwell modem consists of octets 13 through
| 18.
|
Actually, octets 13 to 18 refer to information which is contained in V.8bis
messages and not V.8 ones. Conexants _do_ support V.8 (if you recall,
enabling V.8 and disabling V.8bis at the same time using AT+A8E=6,5,C1,0 did
work) but for some reason no V.8 indications were returned and using #ud/#ug
returns also nothing.
BTW, if you want to have the web page locally, just download
http://users.aias.gr/mpap/v8parser.html and
http://users.aias.gr/mpap/styles/style.css into a directory and change
string "styles/style.css" in the former file to "style.css"
---