Thisa is with regard to FLEET networking over Ethernet. What determines the
length of time it takes a call to functions such as qnx_name_locate() and
qnx_vc_name_attach() to return with failed status when the network is
physically broken (after previously working)? My experiments show it is a
good number of seconds, a time I would like to shorten if this is possible.
Can the timeout be altered?
thanks
Julian Thornhill
Julian Thornhill <jth@ion.le.ac.uk> wrote:
Thisa is with regard to FLEET networking over Ethernet. What determines the
length of time it takes a call to functions such as qnx_name_locate() and
qnx_vc_name_attach() to return with failed status when the network is
physically broken (after previously working)? My experiments show it is a
good number of seconds, a time I would like to shorten if this is possible.
Can the timeout be altered?
Yes it can – but it isn’t completely simple. There are a variety of
timeouts, set in a variety of places, that control this behaviour.
Net -t option (well, it is flipside… how long to recognise one is back)
netpoll – controls how long a vc will last before being torn down
Net.driver – -n, -t – number of tx retries & time between. These are
the main ones to play with. (Note: getting faster failure will make
your network less tolerant of lost packets or high load.)
QNX Training Services
dagibbs@qnx.com
What he said!
If, and only if, you have more than one LAN between any two nodes you can
play with the -n & -t options to most/all od the Net.* drivers. ‘-t’
affects how long a single timeout is, ‘-n’ adjusts how many retries it will
do on a single LAN.
The up side is that if Net tries to send a packet out one lan and it fails,
it will quickly try the other. Example: in a previous life I shipped a lot
of digital audio around radio stations. Every computer had many audio
channels and they played or recorded audio over the network. WIth “WELL
TUNED” redundant networks you could be playing audio and unplug one of the
networks and the audio would keep right on playing. You could then plug
than lan back in and unplug the other lan and the audio would keep right on
playing. And if you were really fast you could actually unplug both lans
and plug them back in (due to some buffering) without ever hearing a glitch
in the audio.
The down side is that if you allow a network driver to give up too soon it
will return errors on packets that would have been successfully transmitted
if you had just given it a few more milliseconds.
–
Bill Caroselli - Sattel Global Networks
1-818-709-6201 ext 122
“David Gibbs” <dagibbs@qnx.com> wrote in message
news:99gfdo$6u7$1@nntp.qnx.com…
Net -t option (well, it is flipside… how long to recognise one is back)
netpoll – controls how long a vc will last before being torn down
Net.driver – -n, -t – number of tx retries & time between. These are
the main ones to play with. (Note: getting faster failure will make
your network less tolerant of lost packets or high load.)-David
QNX Training Services
dagibbs@qnx.com