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

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

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

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

--
Thanks,
Fred.

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?

[s] 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.

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

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.

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

--
--
kensmith@rahul.net   forging knowledge