Data transfer time problem

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

"new77" a écrit dans le message de news: snipped-for-privacy@g10g2000cwb.googlegroups.com...

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

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

But can it?

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.

This is wrong. 72745 bits, in 9093 bytes at 8 bits per byte (that's

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.

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.

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.