[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::digital_unix

Title:DIGITAL UNIX(FORMERLY KNOWN AS DEC OSF/1)
Notice:Welcome to the Digital UNIX Conference
Moderator:SMURF::DENHAM
Created:Thu Mar 16 1995
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:10068
Total number of notes:35879

8895.0. "FDDI data corruptiuon, anyone?" by RDGENG::HAQUE (Shaheed R. Haque, 830-3531, reo2-f/b3) Wed Feb 19 1997 12:47

Digital UNIX V3.2C
DEFEA/DEFPA with V2.46 firmware

Has anyone seen a corruption of FDDI data either from "fta" driver or in the
dlpi/STREAMS interface layer?

What we are seeing is that a driver (a STREAMS module) sitting above dlpi/fta
sometimes sees corrupt datapackets (dlpi_unitdata_ind_t). The corruption is
that a number of bytes, e.g. 44, is mysteriously inserted into the middle of
a buffer.

How we know this is that the data is multiple MPEG packets, with a 0x47 every
188 bytes, and we check this data on the receive side (almost) immediately on
reception in our driver. If we panic the system and them look at the buffer, the
first few MPEG packets in the buffer are OK, and then extra bytes of garbage,
then more legal-looking MPEG packets!

Oh, the MPEG packets belong to a "session". We can run many sessions at 4 Mbps
with no apparant errors, but starting even a single session at 8 Mbps seems to
provoke the problem within a couple of minutes.

	Thanks, Shaheed
T.RTitleUserPersonal
Name		DateLines
8895.1SMURF::GILLUMKirt GillumWed Feb 19 1997 13:494
    
    Is this the real fta driver or the driver that was modified by the
    multimedia layered product you're running.
8895.2RDGENG::HAQUEShaheed R. Haque, 830-3531, reo2-f/b3Wed Feb 19 1997 17:2819
>    Is this the real fta driver or the driver that was modified by the
>    multimedia layered product you're running.

Sorry, I should have made that clear. The transmitting side is a modified
ftadriver but the receiver is a standard ftdriver.

I have enabled the checking in the transmitter ftadriver that *should* catch
anything like this kind of corruption being actually caused by the transmitting
video pump code. It's tricky, but I'll try verify that it does do, just in case.

On the receiving side, I can see thousands of FDDI frames with no error
(millions at the lower session data rates) and then a single frame with the
error.

I am discounting line errors because I assume that the DEFPA firmware would
discard packets with a bad CRC. And anyway, as far as it is concerned, it has no
concept of the session data rate.

	Thanks, Shaheed
8895.3good luckSMURF::GILLUMKirt GillumThu Feb 20 1997 16:174
    
    Drivers are very sensitive, and, when you change them, you take your
    chances.  Corruption is one of those chances...
8895.4SMURF::MENNERit's just a box of Pax..Fri Feb 21 1997 13:555
    Is  either the transmitter or receiver running on a multiprocessor
    platform?  If so do they use the STREAMS DLB pseudo driver?
    
    There is a patch to dlb which fixes a problem of the dlb sending out
    of order packets.  Could this be the problem?
8895.5RDGENG::HAQUEShaheed R. Haque, 830-3531, reo2-f/b3Sat Feb 22 1997 08:036
Thanks for the replies...for the moment, the cold light of suspicion is on the
transmitter, where it looks like the reading-from-disk side might be causing the
problem, rather than writing-to-FDDI.

	Thanks, Shaheed