Data transfer time problem

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?


Reply to
Loading thread data ...

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
 Click to see the full signature
Reply to
Tim Wescott

"new77" a écrit dans le message de news:

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

Reply to
Fred Bartoli

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?

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.

Tony Williams.
Reply to
Tony Williams

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

Reply to
Rich Grise

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.


Adrian Jansen           adrianjansen at internode dot on dot net
 Click to see the full signature
Reply to
Adrian Jansen

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.

Reply to
Joel Kolstad

In article , Joel Kolstad wrote: [....]

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
--   forging knowledge
Reply to
Ken Smith

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.