Re: [bacnet-mstpwg] Should the transmission of extended frames affect max-info-frames?
I am thinking we may want to force a token pass after one large message for reasons similar to the no reply timeout case (18.104.22.168 WAIT_FOR_REPLY Reply Timeout transition).
If we hope to be able to mix old and extended capability devices on the same bus, we probably want to allow several small messages at each token possession but tightly limit the number of big ones. This would keep the token moving at a reasonable speed and force the extended devices to share the wire.
From: "nomeekgeek" <jhartman@...> To: firstname.lastname@example.org Date: 06/19/2012 01:31 PM Subject: [bacnet-mstpwg] Should the transmission of extended frames affect max-info-frames?
Should the transmission of extended frames affect max-info-frames?
I have encountered router and system-controller devices that set max-info-frames to 50 or more. Fifty 30-byte ReadProperty requests and their replies is one thing; fifty 1500-byte IPv6 frames full of XML take 9.7 seconds to transmit at 76800 baud, not including any gaps or overhead.
One might imagine an alternative maximum based on the number of octets sent and received during a token-hold, or the duration of the token-hold.
I just know that things go hinky in a hurry once the token rotation time exceeds the APDU timeout value, since the retries just add traffic and make matters worse.
Yahoo! Groups Links
<*> To visit your group on the web, go to:
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to: