According to Lars Petterson: While burning my CPU.
>
> > As i mentioned in my last post on this problem, there is (in my case) no
> > need to reboot the machine, just try ifconfig scc# down then up the
> > interface add a route,
>
> How does Linfbb handle this? It seem to not like to have it's interfaces
> going up and down. But I have not tested this that much myself so how
> does it work for you. Or do you restart fbb also?
The box concerned on which i run the script, does not have FBB running so i
cant say, i would imagen if the interface goes down then you would need to
restart FBB also.
>
> > The only thing i can say about its cause is, there is in my case only one
> > factor i can see which kills the interface, netrom braodcasts when the
> > interface is busy, after a netrom broadcast of "many" nodes + 150 bingo,
> > down goes the interface.
>
> Ok, could be something, but here we do not send netrom broadcast on the
> interface that goes "down" the most. But perhaps the netrom traffic on
> other interfaces causes this...
>
> > This would lead one tho point to a (memory) buffer problem, i use;
>
> Could be something to look into, I think.
>
> > Interface MTU 512 window 1888 also tryed with 944 same results.
> > Maxkey seems not to make any differance at all.
>
> Could be if you override it too often.
Well everything needs to be looked at very carefully in such a case as many
of us seem to be having troubles.
>
> > I dont think its an interface speed issue here, i have ports on 1k2 4k8 and
> > 9k6, any port using netrom "seems" to cause failures, no netrom and no
> > soft-dcd will allow the interfaces to stay up for eternity, or they do with
> > me.
>
> We uses soft-DCD.
That is a know cause of killing an interface, like i said in one message,
"not" using soft-dcd solved the problem on one machine i run.
>
> > As to the netrom broadcasts "being" the problem i cant say, all i am saying
> > is it "smells" like it.
> > I wonder if others who have this problem are transimitting large netrom node
> > broadcasts.
>
> We do transmit long netrom broadcasts too, but not on the interface that
> goes down the most. But the same thing as for maxframe would hold here
> also. If you send too many netrom braodcast at the same time you may
> trip the maxkeyup that may eventually cause the problem... Perhaps :-)
Yep.
I remember when the driver was in its development stage Joerg DL1BKE keep
trying to convince me to use mode VC instead of DG, his argument was that
mode VC should not have this problem, if i remember correctly, however i
still use mode datagram always have always will.
On a 9k6 interface i use, we have a window of 1888 which allows 4 packets
of 512 bytes to be transmitted at one time, this interface does not use
soft-dcd and has the standard maxkeyup of 7,
bufsize 1024
rxbuffers 20
txbuffers 20
txdelay 5
persist 255
slot 8
tail 8
fulldup 0
wait 2
min 3
maxkey 7
idle 3
maxdef 120
group 0
txoff off
softdcd off
Its the busyest interface i have, the interface is a direct link, no users,
we gain 700+ bytes/sec rates with ftp, we have tryed to flood this interface
to kill it, a thing which we cant seem to do, no matter how busy this
interface is it does not die, it has No netrom, ax25 connections are almost
non-existant and mode datagram is used.
The only noticeable thing is with sccstat, TxUnderruns but that seems not to
do any damage, the ratio is, 111107 packets sent and 32 TxUnder's.
That must say something for stability.
>
> 73 de Lars, sm6rpz
>
> --
> Lars E Pettersson | Chalmers University of Technology
> [EMAIL PROTECTED] | Gothenburg, SWEDEN
>
--
Regards Richard.
[EMAIL PROTECTED]
Merry Xmas to all, and may all your troubles be small (ones).
