From: Sar Saloth (sarsaloth_at_yahoo.com)
Date: 2002-03-14 16:48:00
At 01:30 PM 2002-03-14 +0000, you wrote:
>sleeper75se wrote:
> > Testing the serial port can be done by anybody who can program and
> > owns two computers, so volunteers are welcome. Start a new thread on
> > that topic if you are interested...
>
>I took your challenge, setup a test with a Perl script dumping data at
>115200 baud down a cable with flow control disabled. There was no
>problem on my text-mode P133 laptop keeping up with this data stream
>with the machine unloaded (I was using "cat </dev/ttyS0 | tee log").
>
>However, doing a 'find' or any other large disk operation
>(e.g. starting a program up) did cause it to lose bytes, even when I
>gave the process a higher priority. (I didn't try changing the
>priority of interrupts because I don't know how to do that).
That P133 is probably using a PIO disk controller. I mean that the
processor is waiting for and doing all of the disk IO. With modern disk
controllers, (bus-mastering) and like my PROMISE card, the system spends
much less time in kernel mode. This means that in normal operation, you
probably won't miss anything, although a test like yours might still bog it
down too much. Also, there is a chance that the P133 laptop either does
not have a newer serial port with a larger FIFO or it is not enabled. I
think the current standard is 16 bytes FIFO, although there do exist cards
with 128 byte FIFOs (they cost more than you would like to spend). Also,
there might be a bit difference between NT and 9x with respect to this. NT
is much better about maintaining priority.
Given that the cheapest DELL today is a 1Ghz, the fact that your 133
notebook (and notebooks have slower processing and disks for the same
nominal processor clock speed) worked OK except during your disk intensive
task might actually be a good thing. Forcing the users to not play games
while you are collecting data wouldn't be so bad.
>Loading up the processor (e.g. calculating lots of sines) only had an
>effect when the process was at normal priority. At higher priority
>there was no problem.
>
>This is because we're not using flow-control, isn't it ? I'd
>forgotten about this -- when you have a modem it has its own buffer
>and it does flow-control over the serial cable. (Sorry Jim-M for
>doubting you when you said we'd have problems).
>
> > * Data loss: If data is transmitted at say 56700 bps, data loss will
> > happen. A lot.
> >
> > A solution is to increase the interrupt priority of the serial port
> > interrupt to the highest level. This is untested, but should ensure
> > that no data at all is lost - i.e. you won't need CRC checking.
> > If that doesn't work, we will have to use USB with a large hardware
> > fifo (4kb) for PC's running Windows. Linux/embedded systems can be
> > fixed by installing a real-time kernel.
>
>Does there not exist anything like an RS232 line buffer module --
>something that passes RS232 data through, but has a small memory
>buffer in it, and does flow control ? I mean something very cheap.
>Probably it's called a microcontroller, and we don't want to have to
>have one at both ends of the cable. Oh dear.
>
>
> > For me, data loss/sync loss is not acceptable at all so I will work
> > hard to overcome it.
>
>We have no choice -- we have to get clean data through somehow.
Personally, I will use TCP/IP. I am fed up with serial. That is why I am
ignoring the important synch issue and I might not be any help at all.
What happened to that great TOSLINK idea? with a totally different type of
IO the loss of character problem might be completely different.
Ditto for USB - I would strongly suspect that a USB serial port is not
subject to the same problems as the legacy serial port. USB is very
different. Every USB device is guaranteed a slot to communicate every
1ms(or was it 10ms?), no matter what the OS is doing. A cheap USB serial
port might fix everything.
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:41 BST