Data transfer time problem

[new77]

Transfering data and I'm getting a big difference measured vs
calculated ...

Ascii 7bits+1start+1parity+1stop = 10 bits per character
Baud = 9600
Characters per second = baud / bits per character => 960 characters per
second

File size to transfer = 8.88 kilobytes = 9093 bytes = 72745 bits

(72745 bits/file ) / (10 bits/character) = 7274 characters per file

Hyperterminal transfers file @ 9600 baud via nullmodem cable to another
computer in 12 seconds. My calculated transfer of file is 7274
characters / 960 characters / second = 7.58 seconds.

At 2400 baud , 240 characters per second I get a transfer time of 41
seconds
calculated = 7274 characters / 240 characters per second => 30.3

Why should I be getting such large differences?

Thanks

 

[Tim Wescott]

Transfering data and I'm getting a big difference measured vs
calculated ...

Ascii 7bits+1start+1parity+1stop = 10 bits per character
Baud = 9600
Characters per second = baud / bits per character => 960 characters per
second

File size to transfer = 8.88 kilobytes = 9093 bytes = 72745 bits

(72745 bits/file ) / (10 bits/character) = 7274 characters per file

Hyperterminal transfers file @ 9600 baud via nullmodem cable to another
computer in 12 seconds. My calculated transfer of file is 7274
characters / 960 characters / second = 7.58 seconds.

At 2400 baud , 240 characters per second I get a transfer time of 41
seconds
calculated = 7274 characters / 240 characters per second => 30.3

Why should I be getting such large differences?

Thanks

Perhaps because you're comparing apples to orange lug wrenches?

ASCII (not ascii -- it's an acronym) is just 7 bits. Make it into
serial and it's 7+1start+1parity+1stop = 10 bits per character, but
that's 7 data bits to keep, and 3 to sacrifice to the Protocol Gods.

A file size of 8.88kB = 9093 bytes = 72745 bits, or ideally more than
10000 'ascii' characters to send. If the file is an ASCII text file
then you could get away with 9093 characters, because ASCII is just 7
bits. If it's a binary file then you need to encode it somehow, which
usually uses 6 bits per character -- now you're sending 10 bits with
_four_ sacrificed to the Protocol Gods. Add in some packetizing that
sacrifices whole _characters_ to the Protocol Gods, and you should be
happy that it only takes as long as it should.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google? See http://cfaj.freeshell.org/google/

 

[Fred Bartoli]

Transfering data and I'm getting a big difference measured vs
calculated ...

Ascii 7bits+1start+1parity+1stop = 10 bits per character
Baud = 9600
Characters per second = baud / bits per character => 960 characters per
second

File size to transfer = 8.88 kilobytes = 9093 bytes = 72745 bits

(72745 bits/file ) / (10 bits/character) = 7274 characters per file

(72745 bits/file ) / (7 bits/character) = 10393 characters per file

 

[Tony Williams]

Ascii 7bits+1start+1parity+1stop = 10 bits per character
Baud = 9600

Characters per second = baud / bits per character => 960
characters per second

File size to transfer = 8.88 kilobytes = 9093 bytes...

9093 bytes at 960 chars/sec is 9.47 seconds.

9093 bytes at 240 chars/sec is 37.9 seconds.

That is assuming that the receiving computer can take
9093 bytes in one continuous uninterrupted stream.

But can it?

Hyperterminal transfers file @ 9600 baud via nullmodem cable to
another computer in 12 seconds.
......240 characters per second I get a transfer time of
41 seconds

12 - 9.47 = 2.5 secs error.

41 - 37.9 = 3.1 secs error.

Notice that the overall timing errors are nearly the same.

That could suggest that the receiving computer is not
taking characters in one continuous uninterrupted stream.

It has a limited size buffer, and periodically it has
to request a stop in transmission in order to service
the full buffer. (RTS/CTS for a hardware handshake,
XON/XOFF for a software handshake.)

Actual time = bytes/(chars/sec) + N*Stop-Time.

Where N is the number of Stops, and Stop-Time is the
time taken for each handshake and service of the buffer.

N*Stop-Time will be roughly constant for any baud rate,
which looks like about 2.5 to 3 seconds in your case.

 

[Rich Grise]

Transfering data and I'm getting a big difference measured vs
calculated ...

Ascii 7bits+1start+1parity+1stop = 10 bits per character
Baud = 9600
Characters per second = baud / bits per character => 960 characters per
second

File size to transfer = 8.88 kilobytes = 9093 bytes = 72745 bits

(72745 bits/file ) / (10 bits/character) = 7274 characters per file

This is wrong. 72745 bits, in 9093 bytes at 8 bits per byte (that's
7 plus parity, I presume), but to send those 8 bits, you have to send
two additional bits: start and stop. So actually you're sending
(72745 / 8) * 10 bits = 90930 bits, which could account for some of
your error.

I agree with the rest, about handshaking and stuff.

Cheers!
Rich

 

[Adrian Jansen]

This is wrong. 72745 bits, in 9093 bytes at 8 bits per byte (that's
7 plus parity, I presume), but to send those 8 bits, you have to send
two additional bits: start and stop. So actually you're sending
(72745 / 8) * 10 bits = 90930 bits, which could account for some of
your error.

I agree with the rest, about handshaking and stuff.

Cheers!
Rich

Even if the receiving end doesnt request a delay while saving buffers,
what makes you think the transmit end sends continuously without any
delay between characters ? Typical Windoze certainly doesnt, with all
its overhead for multi-tasking.


--
Regards,

Adrian Jansen adrianjansen at internode dot on dot net
Design Engineer J & K Micro Systems
Microcomputer solutions for industrial control
Note reply address is invalid, convert address above to machine form.

 

[Joel Kolstad]

Even if the receiving end doesnt request a delay while saving buffers, what
makes you think the transmit end sends continuously without any delay
between characters ? Typical Windoze certainly doesnt, with all its overhead
for multi-tasking.

You'd have to dig up a pretty old PC for this to be true; any contemporary PC
that's only trying to push characters through a serial port has far more than
enough buffering in both software (the serial port device driver running in
Kernel mode, which cannot be pre-empted other than through hardware
interrupts) and hardware (usually 16 characters these days) to have no
inter-character gap in its output.

If you're running a dynamic web site hooked up to a SQL server backend on your
PC, then sure, the output most likely will certainly stutter from time to time
with generic PC hardware. There was a time when there were specialized serial
port cards available for PCs that had huge buffers (something like 256
characters) to minimize this problem.

 

[Ken Smith]

You'd have to dig up a pretty old PC for this to be true; any contemporary PC
that's only trying to push characters through a serial port has far more than
enough buffering in both software (the serial port device driver running in
Kernel mode, which cannot be pre-empted other than through hardware
interrupts) and hardware (usually 16 characters these days) to have no
inter-character gap in its output.

Have you tried this. I find it very surprising that Windows always will
drop characters at 9600 Baud when receiving[1] and yet can do full speed
transmit. This implies that it isn't the software not getting back fast
enough that is causing the lost characters.

[1] Win98 at 450MHz lost about 1/100K, XP-Pro at 2GHz lost about 1/300K