SPLIT_TIMEOUT register and ubCore/FireAPI
BruteForce
purpose is to define what is the maximum allowed amount of time between
a transaction request and the corresponding response.
Implementation of the SPLIT_TIMEOUT register is mandatory for all
devices that want to call themselves "transaction capable"
(IEEE1394-1995 8.3.1.2).
The register is located at offset FFFFF0000018. As I said SPLIT_TIMEOUT
is an 8 byte register, so we actually have SPLIT_TIMEOUT_HI at offset
FFFFF0000018 and SPLIT_TIMEOUT_LO at FFFFF000001C. The smallest
permissible timeout is 100msec and the biggest 8 seconds. For the
detailed format of the SPLIT_TIMEOUT register you'll have to look into
your copy of the 1394 standards.
Although every device has its own SPLIT_TIMEOUT register, the value of
the register is logically considered a property of the 1394 bus, not of
the 1394 device. This means that all devices on the 1394 bus should
have the same value in that register.
Whose job is it to make this a reality?
The Serial Bus Manager's of course.
Before we see what ubCore and FireAPI provides with regards to split
timeout management let's see the reason WHY we need the SPLIT_TIMEOUT
register.
For starters some 1394 devices are slower than others. For example
their firmware runs on a slower processor. So they may take more time
to respond than others.
However most devices look cool when they are idle, responding within
the default timeout, but may get real slow when they are very busy
doing other hard work like streaming live image at 30fps.
So in order to avoid these timeouts we have to adjust appropriately the
SPLIT_TIMEOUT register.
Several months ago we added to our Serial Bus Manager driver
(UBSBM.SYS) a couple of very nifty features that relate to
SPLIT_TIMEOUT management. We did that in the process of getting the
1394 Compliance Logo from 1394TA.
UBSBM.SYS does two things:
(1) If UBSBM is the elected serial bus manager and the SPLIT_TIMEOUT
register on its node gets written with a new value, then UBSBM
propagates this value to all linkon nodes on the local bus. This is
done with a separate write transaction for each node, not a broadcast
write.
(2) After each bus reset UBSBM writes the SPLIT_TIMEOUT register of all
linkon nodes on the local bus with the value of its own SPLIT_TIMEOUT
register. So if new nodes joined the bus, they will get synched to the
split timeout value being used. If two buses that are configured with
different split timeouts get joined, obviously one of the two will
randomly win over the other.
Action #2 above is not enabled by default, in order to minimize
post-bus-reset traffic. If it's something you need, you'll have to turn
it on using our infamous UBTWEAK utility. It does not require a reboot
and it automatically restarts UBSBM for you. Now isn't that sweet?
So if you have got a device that gives you lots of timeouts, may be you
should tickle with the SPLIT_TIMEOUT register. If your currently
elected SBM is a ubCore node running UBSBM.SYS, then simply write the
SPLIT_TIMEOUT register on that node and you should be OK.
Supposing the SBM is node 9 then the following command in FireCommander
would set the timeout to 1 second:
write . 9 FFFFF0000018 8 0000000100000000
Please verify that your device really accepts the write to its
SPLIT_TIMEOUT register. It may have returned a resp_complete packet but
completely ignore the new value.
Depending on the sophistication of the device this may or may not
matter. Theoretically a device should NOT transmit a response for a
transaction request after the split timeout has elapsed. ubCore
enforces this rule on the PCs, but then a camera or another device is a
whole business of its own.
In this case you will usually meet no real problem in practice. If the
split timeout has been increased on nodes running ubCore, then they
will accept any answer that arrives in within that timeout, regardless
of whether the responding device has the correct value in its
SPLIT_TIMEOUT register.
Another useful tool for troubleshooting timeouts is of course an
analyzer. There you can see if the device actually sent back a response
packet, and how long it took it to do so.
Needless to say, if the device does not answer then the split timeout
setting is of little use.
We have also noted that some devices, when busy, ignore *some*
requests. That is they respond sometimes and may be a little late as
well. So there you need both a properly adjusted split timeout AND
retries in your transactions.
Currently we don't provide a way for starting up UBSBM with a split
timeout value other than the default. Let us know if you need it.
Dimitris Staikos
Unibrain
PS: Quick quiz. The SPLIT_TIMEOUT register is not implemented by
UBSBM.SYS. How does UBSBM find out about the change in the register
value so that it can update every other node's SPLIT_TIMEOUT?