tvdl@bsiao.UUCP (Timo van der Laan) (07/10/90)
We have a VAX 11/750 running BSD4.3. Since we use a trailblazer (for news), the message "dmf0: silo overflow" gets printed rather often on the console. The trailblazer operates at 19.2 Kb and is the only active 'terminal' when the above message gets printed. Question 1: Is this a serious error? Question 2: Is there a way to prevent it? The next problem is the strange behavior of the ttyh0 line (the first line). It's a real pain to use that line. Output stops often, ^Q is then needed to get something more on the screen. (Whenever I get connected to this line, I use another one). On other lines this problem almost never occurs. Question 3: What is the cause of this behavior? Question 4: Is there a cure? -- Timo van der Laan, Postbank N.V., room 4.94 ...hp4nl!bsiao!tvdl Pb 21009 1000 EX AMSTERDAM Phone: + 31 20 5843175
grr@cbmvax.commodore.com (George Robbins) (07/11/90)
In article <522@bsiao.UUCP> tvdl@bsiao.UUCP (Timo van der Laan) writes: > We have a VAX 11/750 running BSD4.3. Since we use a trailblazer (for news), > the message "dmf0: silo overflow" gets printed rather often on the console. > The trailblazer operates at 19.2 Kb and is the only active 'terminal' > when the above message gets printed. > Question 1: Is this a serious error? > Question 2: Is there a way to prevent it? This isn't unusual - the dmf32 has a fairly small input buffer (silo) and the 750 probably can't keep up to incoming bursts. On our 785 (Ultrix) we would get these messages any time two uucp lines were active at 9600/19200 baud. It's not serious as far as uucp is concerned, some incoming characters are dropped but the protocol eventually recovers. It is something of a problem if you have activity on other lines on the DMF32, since other lines can also lose input when the uucp line overflows the silo. Some interfaces have larger silo's, but they all seem to be on the same order of magnitude. I switched to a Able DH11 emulator board, and the problem occured much less frequently, but didn't go away. Unfortunatly, the Ultrix DH11 driver has some kind of bug that led to system crashes when it did overflow... I'd suggest just ignoring the problem if you can, putting other serial lines on a separate interface if you have difficulties. You may also want to try running the Trailblazer at 9600 baud - in many cases you'll only lose 20-30% of the thruput, but also limit input burst rates. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
gwyn@smoke.BRL.MIL (Doug Gwyn) (07/12/90)
In article <13144@cbmvax.commodore.com> grr@cbmvax (George Robbins) writes: >This isn't unusual - the dmf32 has a fairly small input buffer (silo) and the >750 probably can't keep up to incoming bursts. It ought to be able to, though. My DZ-11 driver was able to keep up on a PDP-11/34. Perhaps the driver is not peeking to see if there is additional input before resuming from a DMF interrupt? Note that some interfaces require time for the silo to "settle" when an incoming byte is removed, and the driver should be sure to not peek before the settling time. This problem seems fixable to me.