[email protected] said: > On 13 April 2010 21:40, Martin Lucina <[email protected]> wrote: > > [email protected] said: > > On 13 April 2010 21:30, Martin Lucina <[email protected]> wrote: > > > > In my opinion the correct way to do this is to have OpenPGM > > reserve e.g. 5% of the requested data rate for RDATA by default, > with > the > > option to configure the reserved bandwidth amount for those who wish > to > > shoot themselves in the foot. > > > > > > > > Unusually SmartPGM is the only implementation I've seen with rate > controls and > > all it has in respect to RDATA vs. ODATA here is to set RDATA to be say > maximum > > 5% of the rate limit - but not to reserve it solely for RDATA. > > So my reasoning is correct when I say that with the current implementation > if I set TWX_MAX_RTE to e.g. 100Mbps, then proceed to publish at 100Mbps > and *any* packet loss occurs, things will break? > > > Correct.
In that case, what is the point of calling pgm_transport_set_txw_secs() at all? My understanding was that if I ask for a 1 second reliability interval then OpenPGM will do "whatever is necessary" to maintain that interval. > I would presume the recommended architecture then would be to remove the back > channel and only use pro-active FEC packets, e.g. satellite bulk transfers. Would it not be simpler to use weighted bandwidth sharing between RDATA and ODATA as mentioned in section 5.1.3 of RFC 3208? OpenPGM already has a rate-limiting engine so presumably this would not be too complex to implement. -mato _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
