Timeout Detection greatly improved
BruteForce
timeout detection. That is, how quickly after a timeout occurs does the
application find out? This is independent of the value of the
SPLIT_TIMEOUT register.
The delay an application sees when a timeout occurs is
(SPLIT_TIMEOUT+DetectionDelay).
It is practically impossible for the Class Driver to make the
DetectionDelay zero. Instead a periodic timer is used that checks all
pending transactions 5 times a second. So the detection delay is on
average 100msec and worst case delay is 200msec.
In pseudo code you would count the timeout detection delay as follows:
for (;;)
{
DWORD dwSplitTimeout = GetSplitTimeout();
DWORD dwStart = GetTickCount();
Status1394 = C1394ReadNode(...);
if (STATUS_1394_TIMEOUT == Status1394)
printf("Timeout detection delay is %d msec\n",
GetTickCount()-dwStart-dwSplitTimeout);
}
It turned out that there was significant delay in timeout detection in
ubCore. This is why applications like FireViewer would appear very
sluggish whenever there was a camera on the bus that flipped and
started timing out all transaction requests.
With such a camera on the bus, another symptom that would occur was
that FireCommander would beep indicating a bus reset 2-3 seconds after
the bus reset had actually occurred. That was because the Plug'n'Play
enumeration was getting transaction timeouts and thus significantly
delaying processing in the Bus Reset handler in the Class Driver.
ubCore 5.11 removes these problems by using a 5Hz periodic timer. We
are considering making the periodic timer configurable through a
registry setting, in order to accommodate time-sensitive applications
that need to minimize average and worst case timeout detection delays.
If you would be interested in that, please contact Unibrain support.
Dimitris Staikos
Unibrain