> From: Paul.Hampson@xxxxxxxxx (Paul Hampson) > Wait, you're trying to send more data than the link can take? Then No, of course I don't expect to send more than the limit. > send UDP, throttle it at the local end with a drop-oldest qdisc. Then > you get the effect of 'most recent data is best'. Anything more Yes, that gives me "most recent is best" but that does not do what I want except in a few weird cases. If every packet is independent, perhaps it would suffice to always send the newest, e.g., if I were trying to tell the other side what's the latest clock time. (In that case I'd also limit the queue length to one.) > You gotta prioritise your data, using TOS or diffserv or something. > Set your voice to real-time, so it always gets sent, and the your > other applications can use unused packet-times. Use a dropping qdisc This may be the best I can do in the current world where the facility I described does not exist. It does not solve the problem I described. TOS/diffserv etc is more for use by the intervening infrastructure and this problem applies even in the case where there is no congestion or delay at all in that infrastructure, but only in the link from the sending machine. Using "real time" is just a matter of giving one application priority over others. First, the link itself may have varying bandwidth, and second the other applications might also have urgent data to send. Dropping packets can be disastrous if they happen to contain critical data that is not duplicated in other packets. At very least I have to be able to find out which ones were dropped. But better than all of that is the ability to decide what to send at the last moment. > I have a vauge recollection that this sort of thing is discussed in > Tannenbaum's Computer Networks textbook, to do with positional data > of satellites or something. (eg. if the positional data is delayed, > we write it off, we don't want to delay the data about where we are > _now_ in order to know where we were _then_) If the goal is to listen to the sound from .2 sec ago and it takes .1 sec to get there then clearly it's a waste of time to send data that's older than .1 sec. But the packet in the queue might have some data that's older and some that's newer. I can't drop part of it. Instead I'd like to know that the packet is about to be sent now, and respond by finding the best data to send now. > From: Ed W <lists@xxxxxxxxxxxxxx> > This is a total pain to optimise. Ideally I would like an API to be > able to limit the congestion window on the local machine for a > particular connection (which I don't think exists on either windows or > linux?). This way the OS will report that the queue is full quickly to > the local program without buffering up a ton of data. > > The issue in my case is that you have two simultaneous streams in > transit for email, one to receive new mail and one to send mail out. In > the case of the sat phone it's possible to have net buffers which are 20 > secs or so long and so when you send out a status message to say "email > received successfully, send me the next one", it can end up queued > behind a bunch of lower priority data for a VERY long time. Often these > buffers are on the remote ISP end where you have very little control. > This is a serious slowdown on a link which is costing you $1.50/min. I'm not sure I follow the problem, but if you're saying that one stream should have priority over the other, it seems you could do that with two different queues, one with priority over the other. Or something like sfq could at least prevent one connection from waiting for the other to send a lot of data. _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
