On Tue, Apr 02, 2002 at 06:14:52PM +1000, Brad Hards wrote:
> On Tue, 2 Apr 2002 17:32, Stuart Lynne wrote:
> <snip>
> > The network and serial drivers have optional CRC checking across all
> > bulk transfers (to compensate for problems with StrongARM and Linkup
> > FIFO implementations).
> I am not sure what this is meant to do. I don't think anything at the link
> layer can provide a truly reliable protocol because the operating system
> will still drop interrupts, etc. To my way of thinking, this needs to be
> solved at the transport layer (eg TCP/IP). If you still have to run a
> reliable transport over the top, wouldn't it just be easier to leave out the
> CRC stuff? Note that I don't have a proper linux device (no Zaurus in
> Australia :(), and my experience is with modified consumer cable modems, so I
> don't know how bad things can get...
The CRC is not there to give you a reliable protocol in the sense that
data transfer is guaranteed to be delivered.
It is only there to guarantee that we do not accept corrupt data. If the
data is corrupt we want to drop it and let higher level protocols do
what they want to recover.
This is generally the right thing to do for networking.
For serial, at least if you are doing PPP over serial (over USB) etc it
is also the right thing to do.
I suspect interactive users of a serial link would (slightly perhaps)
prefer data to be dropped instead of being silently corrupted.
The problem that both the StrongARM and Linkup have is that while the
USB hardware will CRC the data being sent on the bus and verify the
data being received on the bus, neither device guarantees that we can
fill the FIFO for sending or reliably unload the received data. And
also in both cases gives us no way to verify if we have.
The StrongARM will occasionally ignore reads on the receive data FIFO
for example. Which may get caught (too many bytes) if we are receiving a
full sized USB packet but will not be noticed if we are receiving the
last (not full sized) packet of a bulk transfer. Without CRC we have
just added an extra byte somewhere in the last 8 bytes of the ethernet
frame if we had an ignored read. And no way to detect that without a
CRC.
The Linkup has a poorly implemented FIFO design. If we are filling the
transmit FIFO while the device is filling the receive FIFO one or the
other FIFO update simply gets ignored (the FIFO pointer is advanced but
the data remains what is previously was).
> > The network driver configuration uses a new CDC Class extension that
> > allows CDC type configurations to be implemented using a single
> > interface and two bulk endpoints.
> New extension as in version 1.2? Or new extension as in "not quite like the
> CDC spec"?
This is a new protocol which uses newly defined extensions defined in
the Wireless Modem Communication specifications.
This was designed by MCCI to allow them to move their Windows Driver in
a direction that could support our network devices. The basic premise
being that they likes CDC capabilites, but I could not implement CDC
everywhere because it requires two interfaces, a data interface with two
possible values for alternate setting, two bulk and an interrupt
endpoint.
All or some of which may or may not be always available. First there is
the StrongARM which lacks the interrupt endpoint. Then the Linkup which
supports two interfaces (well almost, it was supposed to) but not an
alternate setting which is non zero. Then the hitachi which has only
only one interface.
We noted the trend and MCCI responded with the MDLM specification.
I'll ask them when we can get the the specification document released.
MDLM may go through another revision to add one more extension to fix a
Windows USB problem. Windows does not seem to be capable of scheduling a
new URB for sending until the end of a frame. This has two ramifications.
First lower throughput on file downloads because there is on average a
half a milli-second delay after each URB before starting the next.
Second there is an absolute limit of 1000 URBS per second that can be
sent. Which can cause a problem if your traffic has a lot of small
packets. So MCCI would like to extend MDLM with a slightly more
elaborate protocol wrapper that would allow them to queue multiple small
bulk transfers until a single URB before passing to Windows to be sent.
> I am the CDCEther maintainer, and I'd like to see the CDC Ethernet model code
> from current driver and usbdnet merged to a common driver, so that we don't
> get even more confusion. Can you add me to your maling list when ready (or
> perhaps you could just use the existing linux-usb-[devel, users] lists).
I'm open to doing that. If the current users on these lists don't object.
> In the mean time I'll take another look at the CRC code.
It is simply a 32bit CRC appended to the frame. With two wrinkles. First
because Zero Length Packets are not always possible we don't rely on
them. So to terminate a bulk transfer we need to append a byte to all
transfers if they would otherwise be a multiple of the packetsize. This
is added *after* the CRC.
So the receiving code has to compute the CRC across the bulk transfer,
less one byte if the size is one greater than a multiple of the
packetsize. If it succeeds toss the remaining byte, if it fails add the
remaining byte to the CRC computation and check again.
The second wrinkle is that there is a special option that is currently
used for the Linkup device. It's FIFO implementation is so bad that it
literally cannot operated correctly unless full sized packets are always
used. So we have to pad the bulk transfer to be a multiple of the packet
size less five bytes, and then append the CRC. [Yes the Linkup works ok
for packet sizes 1 or 2 bytes less then full sized.]
The serial CRC is different. All data is transferred as a single usb
data packet, with the last two bytes containing a 6 bit quantity showing
the actual data payload size and a 10 bit CRC.
We have not seen to many people using serial it is just to slow compared
to the network driver (60,000 bytes/second vs 850,000 bytes/second on
file transfers to the Zaurus from a Linux host).
> Thanks for releasing this.
>
> Brad
--
__O
Lineo - Where Open Meets Smart _-\<,_
PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68
Stuart Lynne <[EMAIL PROTECTED]> www.lineo.com 604-461-7532
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
