Re: [LARTC] checksum update in TCP
On Mon, Jan 20, 2003 at 03:09:57PM +0100, devik wrote: Or imho even more probably, the problem could be the line. I've had a couple of these during last 3 years. Namely, is there a serial line (possibly wireless) involved? Yes it is. There is wireless net inbetween. But interestingly I have seen no other packet corruption except when communicating via FTP with concrete W2k user. He can FTP with others as I can too but can't between themselves. Also how could wireless link change data inside of a TCP packet ? Then checksum should become wrong and the packet rejected ... ? Yes, they should. What I had in mind was a data-dependent bug on a 2 Mbps wireless link that caused packets having alternate zero and one patterns in it (0x or 0x) to be dropped by the link and never seen by the receiver. Now, I'm not sure what the exact symptoms are of what you are solving. If your problem is that the TCP transmission completes successfully (i.e. everything's OK as far as TCP is concerned) but the data that came out of the pipe is different that the data that had been sent, that should be a different problem. I changed proftpd to compute and log MD5 of each chunk of data going out of read() syscall so I will be able to compare them to file on HDD (catching errors in FS, IDE (DMA) or HDD). Also in the same time I'll save tcpdump's raw packets to be able to compare stored data with packet contents (with 100MB ftp file it will be a lot of fun :-( ) Can you produce a binary diff of sent and received file to see how exactly they differ? Are the two files completely different? Or do they differ just in a couple of places? Is something missing? Is something changed? If so, how? That's how I managed to isolate some difficult data-dependent bugs, it might be useful here, too. pvl ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] checksum update in TCP
On Mon, Jan 20, 2003 at 10:23:16AM +0100, devik wrote: Hi, anyone knows when TCP checksum is updated ? Normally, TCP checksum is not supposed to be changed (or even read) at all during transfer (see rfc793 or TCP/IP Illustrated Vol.1). If NAT is in use then it needs to be accounted for, of course, because TCP chksum involves a pseudoheader which contains both source and destination addresses - but this is not the case, as you say. On other side if it simply passes packet thru (because nothing except TTL is changed and TTL is not part of TCP checksum) then the checksum should really ensure that nothing is changed between sender and reciever and if data are invalid then error would be on sender's or reciever's side. Or imho even more probably, the problem could be the line. I've had a couple of these during last 3 years. Namely, is there a serial line (possibly wireless) involved? pvl ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB: quantum vs. burst
On Thu, Jan 16, 2003 at 09:28:17PM +0100, Stef Coene wrote: If you want to undestand what's going on, you also have to graph the tokens and ctokens. Oh, I see. The negative values of tokens and ctokens that can be seen frequently are because of the hysteresis setting? Also, I have some trouble understanding the tokens/ctokens example on www.docum.org. First, I would suggest that you add an additional bullet specifying initial conditions more explicitly. I suppose that the burst bucket is filled up when the 200bps transmission starts, am I right? Second, it would be useful to state what ceil the example class has since bursting is limited by ceil as we agreed before. Without knowing the class' ceil it's hard to say at what speed the first burst bytes will be released to the network - which is what the other calculations depend on. I use the ethloop from Devik. It's a very nice think ones you understand how it works. I can send you my scripts and config files if you are intersed (and I think you are :) You bet I am, thanks a lot. :) Indeed. I think I need some sleep :) Indeed, the ceil is respected if you use the burst parameter. It's the parent ceil that's broken. That brings up a question: what happens if the parent, say 1:20, has its own parent, say 1:10, and the 1:10 has already been overlimit. In other words, class 1:10, already transmitting at its ceil speed, has a child 1:20 that breaks its ceil because one or more its own children are bursting. Unevitably, 1:10 is forced above its ceil too, right? If that is the case, the state of being overceil will spread all the way up the class hierarchy to the root class? I had a hard time finding the directory where I stored my files :) But I found it. Now I have to figure out what I wanted to document :) Oh, don't feel pressed, take your time, it's been a long time coming anyway. ;-) pvl ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB: quantum vs. burst
On Thu, Jan 16, 2003 at 08:05:24PM +0100, Stef Coene wrote: No. I did some tests my self witb burst and cburst. The problem is that it's very difficult to measuer and explain it. You have to believe Devik that it works :) I'm not saying that I don't believe him. ;) However, bursting within complex multilevel hierarchies can bring about a number of rather opaque interactions. If you need to be able to understand this (in other words, to know what you are doing), the basic info from the docs is just not enough. And burst is not made for big bursts like you did. Yeah, I know. I'm not saying this is a realistic scenario. I set it this big just to see it properly in the dumps and graphs. It also helps if you disable HTB_HYSTERESIS in the htb qdisc. See faq page for more info. Take a look at the 1:76's graph if you care - see that depression between 140. and 170. second? It's not there because of lack of demand - 1:77 is still asking for bandwidth. It's probably 1:76 retaliating for being pushed above its ceil between 10. and 40. second. If I understand the docs correctly, the depression should not be there since I *did* set 1:76's burst, too. I was thinking about disabling HTB_HYSTERESIS in hope that doing so would remove this problem but I haven't tried it yet. - back to your example - I'd even dare to say that the class you described wouldn't profit from setting burst at all *unless* there's another class competing for the bandwidth. (If there is a contention, the burst setting will matter.) Can you confirm this? No. If you have a 10kbyte/s link and you have a class with ceil = rate = 5kbyte/s and a big burst/cburst (100.000byte or so), you can measure the burst. The first 100.000 byte will be sended by the burst so it will be sended in 10 second. I just repeated the experiment with the exception that only 1:78 (the one with burst set) was asking for bandwidth (the competing 1:77 was silent) and I'm afraid that I'm not able to see any burst anyway. In my view, burst won't let me break my ceil. However, cburst will. I have some very detailed information about how the burst and cburst from parent and child classes are interacting, but I still have to create a page for it. It also explains how burst and cburst can exists and how the tokens and ctokens are changing when you are using the burst. Maybe something I can do tonight. I will keep you informed. That would be *great*. :-) pvl ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] new HTB - call for participation
On Fri, Apr 26, 2002 at 09:53:00AM +0200, Martin Devera wrote: I have almost finished second attempt for the next HTB generation. The first one (not the one publicaly available) based on hierarchy of counters was too complex and yelded only cca 30% speed improvement. Current test one is based on hierarchy of RB-trees and what remain to do is to implement walking over these trees (update is done) and then test and measure it. I hope in much better speed and scalability. If someone is interested in such work and become co-author let me know. The main problem lies in my time shortage so that I'm not able to work at it too often. Where is the new code? pvl ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] new HTB - call for participation
On Fri, Apr 26, 2002 at 10:55:01AM +0200, Martin Devera wrote: The new code is private at this time - it can't be compiled - in reality I;m working on it 4 weeks and I never tried to compile it ;) I'll create web page for it at luxik.cdi.cz/~devik/qos/ in hour or so .. OK, thanks - it's hard to say I want/can do it if one is not really sure *what* exactly needs to be done. ;-) pvl On Fri, 26 Apr 2002, Pavel Mores wrote: know. The main problem lies in my time shortage so that I'm not able to work at it too often. Where is the new code? ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] weight parameter in htb?
On Tue, Apr 02, 2002 at 03:34:08PM +0200, Martin Devera wrote: E.g. you might have a customer agency which needs say 256 kbps for its headquarters and 64 kbps for its factory. They pay for 512 kbps which means that they buy 512-256-64=192 kbps of excess bw available to both sites on demand. Well, it makes sense to me that they would be worried about the headquarters class draining the other class in case both classes have demand. They might want to say We buy lower rate for our factory because Internet access is rarely needed there. But *when* it *is* needed we want to let the factory take at least 1/2 of the excess bw we buy even if headquarters demand excess bw too. We already buy 256 well, you are right. However you should take into account that even in cbq the weight is not precise argument. It influences excess distribution but you will see some discrepancies. Yes - this and other CBQ problems are the very reasons I'm looking into alternatives. :-) CBQ's weight parameter semantics is rather opaque and it is difficult to predict how a given weight value will influence excess bw distribution. I also suspect that CBQ's weight doesn't give me complete independence on rate ratios although I'm not sure here (yet). As I'm working on new version I'll try to do it - if it will not slow things down. It is because with assmption that weight is proportional to rate we can make some algorithms faster ... We will see ;) Then I hope it will be possible to implement it in such a manner that it wouldn't hurt those who don't use it. Anyway, thanks a lot. :-) pvl ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
