From falk at ISI.EDU Wed Mar 10 15:37:08 2004 From: falk at ISI.EDU (Aaron Falk) Date: Wed Mar 10 15:37:16 2004 Subject: [xcp] considering a web100 port for XCP Message-ID: Matt- Given the popularity of the Web100 kernel with the folks I saw working on high-performance transport protocols at PFLDnet, we're considering doing a port of the XCP end-system code. Do you think there would be benefit to porting the router code to the Web100 stack as well? Does it include optimizations of the Linux routing code? Thanks, --aaron -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://gamma.isi.edu/pipermail/xcp/attachments/20040310/72460055/PGP.bin From falk at ISI.EDU Wed Mar 10 15:49:25 2004 From: falk at ISI.EDU (Aaron Falk) Date: Wed Mar 10 15:49:29 2004 Subject: [xcp] notes from XCP weekly meeting 3/10/04 Message-ID: <8FD72847-72ED-11D8-A682-000A95DBDB84@isi.edu> - Yuri Pryadkin joins team to do programming & analysis. Initial responsibilities: maintaining BSD code, looking at router code optimizations, improvements to header format - Aaron to send Yuri web100 page URL - idea: have Yuri look at/do Chiarro implementation? - Aaron to send note to matt asking whether web100 would be good page to build router code - Yuri to look at diffs between web100 and other linux distributions... - Ted to give Yuri a docbook copy of Ted's code description from final Activate report - Ted to give Yuri CVS access & diffs - Aaron to email Eric about switch quote -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://gamma.isi.edu/pipermail/xcp/attachments/20040310/f3c1c440/PGP.bin From mathis at psc.edu Wed Mar 10 17:03:48 2004 From: mathis at psc.edu (Matt Mathis) Date: Wed Mar 10 17:04:23 2004 Subject: [xcp] Re: considering a web100 port for XCP In-Reply-To: Message-ID: Web100 is strictly for TCP.... autotuning + instrumentation + other CC algorithms (net100 actually). I would say yes for your TCP implementation, no for your router implementation. However, we occassionaly toy with the idea of taking our web100 release machinery and turning it into a "NSF Linux" release machinery... This could naturally include both parts of XCP and a whole lot of other interesting stuff. Currently the chances are slim, but as more people express interest, we will thinks about it. Thanks for the interest! --MM-- On Wed, 10 Mar 2004, Aaron Falk wrote: > Matt- > > Given the popularity of the Web100 kernel with the folks I saw working > on high-performance transport protocols at PFLDnet, we're considering > doing a port of the XCP end-system code. Do you think there would be > benefit to porting the router code to the Web100 stack as well? Does > it include optimizations of the Linux routing code? > > Thanks, > > --aaron > -- --MM-- ------------------------------------------- Matt Mathis http://www.psc.edu/~mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- A good plan today is better than a perfect plan tomorrow. - Gen Patton From falk at ISI.EDU Fri Mar 12 15:17:38 2004 From: falk at ISI.EDU (Aaron Falk) Date: Fri Mar 12 15:17:51 2004 Subject: [xcp] Re: considering a web100 port for XCP In-Reply-To: References: Message-ID: <740C2955-747B-11D8-B809-000A95DBDB84@isi.edu> On Mar 10, 2004, at 5:03 PM, Matt Mathis wrote: > Web100 is strictly for TCP.... autotuning + instrumentation + other > CC algorithms (net100 actually). Thanks for the info, Matt. Another ignorant question: can you help me understand the difference between web100 and net100? Thanks, --aaron -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://gamma.isi.edu/pipermail/xcp/attachments/20040312/2915b32f/PGP.bin From mathis at psc.edu Sat Mar 13 18:18:37 2004 From: mathis at psc.edu (Matt Mathis) Date: Sat Mar 13 18:19:25 2004 Subject: [xcp] Re: considering a web100 port for XCP In-Reply-To: <740C2955-747B-11D8-B809-000A95DBDB84@isi.edu> Message-ID: When we started, Web100 took a purest stance about TCP tweaks: we only considered features that made sense everywhere in the Internet, and expressly excluded things that might reduce TCP's applicability some environments. On the other hand, Net100 accepted anything that seemed useful to DOE (or other interesting environments), including features that were experimental, known to be "unsafe" or that might limit TCP's applicability in low performance environment. However, for our own sanity we kept everything in a single CVS tree with ifdefs to strip out net100 at *release* time. As the net100 code matured (mostly through better runtime controls) we progressively moved it to the web100 releases. There is still a little stuff that is net100 only - mostly not fully baked research code, or single use hacks^H^H^H^H^H features that don't belong in the release. Most of the code that was originally net100 now appears in the web100 release under both runtime and build time conditionals. The CCR paper covers alot of this. I hope this helps. Thanks, --MM-- On Fri, 12 Mar 2004, Aaron Falk wrote: > On Mar 10, 2004, at 5:03 PM, Matt Mathis wrote: > > > Web100 is strictly for TCP.... autotuning + instrumentation + other > > CC algorithms (net100 actually). > > > Thanks for the info, Matt. Another ignorant question: can you help me > understand the difference between web100 and net100? > > Thanks, > > --aaron > > -- --MM-- ------------------------------------------- Matt Mathis http://www.psc.edu/~mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- A good plan today is better than a perfect plan tomorrow. - Gen Patton From thomas.r.henderson at boeing.com Mon Mar 15 13:02:37 2004 From: thomas.r.henderson at boeing.com (Henderson, Thomas R) Date: Mon Mar 15 13:08:30 2004 Subject: [xcp] website update Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040604FE@xch-nw-27.nw.nos.boeing.com> Aaron, I had a couple of questions on slides 18-19 of your PFLD charts. i) on slide 18, what is it about the sender side computation that is influenced by the RTT (I was surprised to see that CPU reached 100% and the performance tailed off seemingly as a function of RTT)? ii) qualitatively, what is going on with the TCP flows that is causing throughput degradation from time 100s onward? At the very least, I would expect to see linear build of cwnd-- there shouldn't be appreciable congestion. Thanks, Tom > -----Original Message----- > From: Aaron Falk [mailto:falk@ISI.EDU] > Sent: Friday, February 13, 2004 10:25 PM > To: xcp@ISI.EDU > Subject: [xcp] website update > > > Folks- > > I've put the PFLD charts, a draft XCP specification, and a > copy of our > kernel implementation on the XCP website at > http://www.isi.edu/isi-xcp. > Please send comments on any of these to this list. > > Regards, > > --aaron > > _______________________________________________ > xcp mailing list > xcp@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/xcp > From falk at ISI.EDU Mon Mar 15 13:46:45 2004 From: falk at ISI.EDU (Aaron Falk) Date: Mon Mar 15 13:46:49 2004 Subject: [xcp] questions on measurements of changing RTTs In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040604FE@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040604FE@xch-nw-27.nw.nos.boeing.com> Message-ID: <41465B76-76CA-11D8-AEC6-000A95DBDB84@isi.edu> On Mar 15, 2004, at 1:02 PM, Henderson, Thomas R wrote: > Aaron, > I had a couple of questions on slides 18-19 of your PFLD > charts. Tom- I updated the slides with the final version I showed at PFLDnet and I think you are referring to what is now slides 20 & 21 from http://www.isi.edu/isi-xcp/docs/falk-pfld04-slides-2-16-04.pdf . > > i) on slide 18, what is it about the sender side computation > that is influenced by the RTT (I was surprised to see that > CPU reached 100% and the performance tailed off seemingly > as a function of RTT)? We believe this is due to the CPU required to traverse the MBUF chains to release cached packets when ACKs are received. At 50Mbps per-flow bottleneck bandwidth and width 650ms RTT, each flow has over 4,000 packets outstanding. Yes, this search could be optimized but we haven't been trying to fix limitations in BSD stack (worrying more about getting the bugs out of our own code). When running BSD TCP we see the same effect so we believe this is not an XCP-related phenomenon. I understand that Linux TCP does better and this is one reason we're interested in porting our end-system code to Web100 (or Net100, I guess). > > ii) qualitatively, what is going on with the TCP flows that > is causing throughput degradation from time 100s onward? > At the very least, I would expect to see linear build of > cwnd-- there shouldn't be appreciable congestion. I think what is happening is that TCP RTOs, possibly multiple times, early in the experiment (when the delay increases are large compared to the current RTT). At the large delays, once TCP gets into CongAvoid it's all over and the window never gets big again. I'm open to other interpretations, though. If you want to take a look at the tcpdump, we can make it available. Thanks for your questions! --aaron From thomas.r.henderson at boeing.com Mon Mar 15 14:51:12 2004 From: thomas.r.henderson at boeing.com (Henderson, Thomas R) Date: Mon Mar 15 14:55:30 2004 Subject: [xcp] questions on measurements of changing RTTs Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040604FF@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Aaron Falk [mailto:falk@ISI.EDU] > Sent: Monday, March 15, 2004 1:47 PM > To: Henderson, Thomas R > Cc: xcp@ISI.EDU > Subject: Re: [xcp] questions on measurements of changing RTTs > > > ii) qualitatively, what is going on with the TCP flows that > > is causing throughput degradation from time 100s onward? > > At the very least, I would expect to see linear build of > > cwnd-- there shouldn't be appreciable congestion. > > I think what is happening is that TCP RTOs, possibly multiple times, > early in the experiment (when the delay increases are large > compared to > the current RTT). At the large delays, once TCP gets into CongAvoid > it's all over and the window never gets big again. I think what may be going on here is that the increase in sending rate due to linear cwnd build is being more than offset by the decrease in rate due to larger RTT and limited window. e.g. at 1 sec RTT, assume cwnd = x segments (about 150 full-sized segments gives you close to the roughly 2 Mb/s). You are sending approx. 150 segments/sec. Now, after 10 seconds of this type of operation (10 windows of data), you will have added roughly five segments, assuming dupacks and no byte counting, but incremented RTT by 0.050 sec: now you can send 155 segments every 1.05 sec, or about 148 segments/sec. By the way, what do the error bars on the new plots represent? Tom From falk at ISI.EDU Mon Mar 15 15:21:18 2004 From: falk at ISI.EDU (Aaron Falk) Date: Mon Mar 15 15:21:28 2004 Subject: [xcp] questions on measurements of changing RTTs In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040604FF@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040604FF@xch-nw-27.nw.nos.boeing.com> Message-ID: <768016AA-76D7-11D8-AEC6-000A95DBDB84@isi.edu> > I think what may be going on here is that the increase in sending > rate due to linear cwnd build is being more than offset by the > decrease in rate due to larger RTT and limited window. > > e.g. at 1 sec RTT, assume cwnd = x segments (about 150 full-sized > segments gives you close to the roughly 2 Mb/s). You are sending > approx. 150 segments/sec. Now, after 10 seconds of this type of > operation (10 windows of data), you will have added roughly five > segments, assuming dupacks and no byte counting, but incremented > RTT by 0.050 sec: now you can send 155 segments every 1.05 sec, or > about 148 segments/sec. > Sounds plausible to me. > By the way, what do the error bars on the new plots represent? We take the average throughput over an RTT by looking at number of bytes sent in that period. The error bars are the standard deviation over the set of averaged throughputs. --aaron -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://gamma.isi.edu/pipermail/xcp/attachments/20040315/4713f562/PGP.bin From falk at ISI.EDU Wed Mar 17 17:07:01 2004 From: falk at ISI.EDU (Aaron Falk) Date: Wed Mar 17 17:07:35 2004 Subject: [xcp] notes from today's project meeting Message-ID: <9045B67A-7878-11D8-8FFE-000A95DBDB84@isi.edu> Status - Eric is back (sort of) - Yuri is finding bugs in BSD OS and XCP code; cleaning up code in end-system and router - Aman made some plots of BTA, BTF, rtt_avg - Padma has XCP-only traffic working using the diffserv queue model, still working on mixing XCP & TCP. Has some questions about Dina's approach to sharing capacity between XCP & TCP. (need to re-read this section in Dina's thesis...) Some problems running Dina's 'parking lot' script. Simulating kernel code. Yuri proposed putting algorithm code from BSD implementatin into ns to make it easier to identify, e.g., variable overflows. Suggested strategy is to quickly find a good fork point in ns development, then let Yuri check out a copy and make then changes he wants. Padma will report next week on when a reasonable fork point will be. Tasks 1. add support for multiple XCP instances (Aman) 2. add support for dummynet output queue (Aman) 3. net100 port of end-host code (Yuri) 4. investigate moving machine 'hog' to 2nd fl. racks (Ted) 5. research strategies for generating mice, elephant, and freighter (much larger than elephants) background traffic, discuss it at next mtg (Eric) 6. generate equipment requirements for extending testbed, minimum new configuration: 3 routers & 6 hosts (Eric) 7. include validation scripts in ns-2 XCP code (Padma) Planned experiments 1. TCP/XCP together 2. repeat earlier experiments with representative satellite config 3. flows w/different RTTs sharing same queue From falk at ISI.EDU Fri Mar 19 14:15:29 2004 From: falk at ISI.EDU (Aaron Falk) Date: Fri Mar 19 14:16:42 2004 Subject: [xcp] a generalized router model for XCP Message-ID: [I'm forwarding this note (with permission) from John Wroclawski. We had been discussing challenges in mapping the XCP model of 'router congestion' to the Cisco 7200. Below, John proposes that we need a more general model of 'congestion' in a router than just queue occupancy and outbound link utilization.] John- I've been over your note (below) several times and let it sit and I still can't visualize what a "response curve normalizer" might look like for anything other than a queue. Can I persuade you to throw us some more hints (so we can try building such a thing). Even when talking about another queue, I can't see how you could allocate congestion feedback to a flow other than running an isolated instance of XCP on that particular queue. But I don't think this is what you had in mind. --aaron Begin forwarded message: > From: John Wroclawski > Date: January 19, 2004 7:27:47 PM PST > > At 9:29 PM -0800 1/16/04, Aaron Falk wrote: >> >> Courtesy of jtw, I found this link at Cisco for the 7200 series >> router (with block diagram), he was able to glean some useful >> information about the thing. I was not. >> >> http://www.cisco.com/en/US/products/hw/routers/ps341/ >> products_tech_note09186a0080094ea3.shtml >> > > Hi, > > The above got me to thinking a little bit. Here're a couple of > thoughts. Forgive me if this is all obvious. > > 1) I did in fact find the referenced document useful. Here's a quick > summary of a couple of points that I think I learned. > > - The basic design of the router is fundamentally identical to a > dual-bus PC, and in fact almost everything IOS is doing here is > directly analogous to things that have been done or discussed for fast > BSD routers. I think there's very strong overlap in the conceptual > problem of implementing XCP in the two environments. (See 2) below for > more..) > > - Summary of the 7200 hardware and processing model: > > Basically, you've got a very traditional hardware design that looks > just like a PC: a CPU board with some system memory and two PCI > controllers, and a set of interface cards that plug into the PCI > busses. There's more to the hardware, but it's irrelevant. PCI address > space is, er, addressable, and the interface cards may have some > memory on them too. It's not explicitly stated, but the operational > description, if accurate, makes it clear that there's a single > system-wide address space - that is, that memory anywhere in the > system (system board, any interface card) can be addressed and read by > any and all parts of the system (CPU, other interfaces, etc). > > Packet processing: > > - Each interface maintains an input ring buffer of (I presume > fixed-size) memory blocks called particles. The memory can be in > different places, depending on the interface. Other than for > performance, it doesn't matter, because all memory is addressable by > everything. > > - when a packet arrives it's placed by the interface hardware in a > linked list of however many particles it takes to hold it, and a > receive interrupt issues. > > - The receive interrupt handler tries to fast-switch the packet. There > are a couple of reasons it might fail: either lack of resources or > lack of information in the route cache. But if it succeeds, the _same_ > particle buffer structure, updated with new header information, is > passed to the output interface for transmission. If it needs to be > queued, it gets queued at the output interface. > > - If it can't be fast switched, it's copied into a single contiguous > "system buffer" and passed off to the rest of IOS for processing. I > can't remember if it says explicitly, but this pretty much implies a > queue between the interrupt level and the process level. Once IOS gets > it, it does whatever it needs to do and schedules the packet for > transmission; queueing it at the output interface if need be. > > So, there are several different places that packets can accumulate; > some of which are interface-specific and some of which are global. > Where packets accumulate in any specific circumstance is somewhat > complicated, and depends on the balance of various resources. > > Now, a useful observation is that the above is a nearly universal > truth. With rare, if any, exceptions, _all_ routers have the property > that there are a number of different resources that can cause > "congestion" if they run short. We tend to want to think of the state > of some queue as the only measure, but that's actually very > simplistic. > > So, 2) It may be useful to think about BSD routers in a little more > detail. It's true that the normal case is that packets are queued at > the output interface. But this isn't the whole story. There are > several places that "congestion" can occur in a BSD router, depending > on circumstance. The obvious one is at the interface output queues. > Another one is in the IP input queue. In this case, the scarce > resource is almost certainly processor CPU, not bandwidth. But it's > still congestion. Another possible place for "congestion" is in the > input buffer ring of an interface; if you're running out of input > memory you're going to either drop packets or flow-control the > interface, in some weird circumstances this could happen even in the > presence of adequate output bandwidth and CPU. Another possibility is > memory bandwidth. Etc. > > A thing that's interesting to note is that which of these different > congestion events "matter" (ie, are enough of a bottleneck to be > important) at any moment depends very much on the dynamic operating > point of the router. Also, the "response curve" of the different types > of events may differ greatly - for example, you might think of a queue > as mushy - it can be either a little or a lot full - but a bus or > perhaps a CPU congestion event is much more binary. > > Again, the above is a nearly universal claim, although at present we > have only the two worked examples of BSD and the 7200. So, i suggest, > what's needed is a conceptual model for an XCP router that looks like > this: > > a) there are several possible congestion event monitors or sensors or > transducers, one for each resource that, in practice, could run out > and cause congestion. (it might be OK to ignore ones that could in > theory run out but can't in practice because of system /hardware > design). > > b) each of these transducers feeds a "response curve normalizer" that > remaps the signal into some form that can be directly compared against > other normalized signals. This normalizer function may also be able to > deal with lack of resolution or accuracy in the input sensor (ie, a > hardware FIFO queue that only tells you "almost full" and "almost > empty", not the exact occupancy). > > c) There's a "congestion source integrator" that considers all of the > signals decides which, if any, of the signals matter at the moment. > The simplest one would, of course, conclude that there're either 0 or > 1 bottlenecks and take the max of all signals. A more complex one > might add some contribution from other signals that weren't the major > bottleneck but were also creating congestion. > > The output of this integrator becomes the congestion indication used > by the XCP algorithm. > > A question I ducked above is what to do about the distinction between > resources that create congestion of different granularities. For > example, in BSD we have the CPU, which can create global congestion, > and output interface bandwidth, which can create congestion on only > one interface. There are in fact intermediate granularities as well. > The 7200 might (I don't know) have an intermediate granularity of one > PCI bus, for example. in any case, lager-granularity congestion has to > be apportioned to particular interfaces (or whatever the finest > granularity is) according to some algorithm - there are a couple of > possibilities that trade off simplicity and efficiency (and fairness). > > Anyway, I suggest that defining and documenting such a conceptual > reference model, and then building an implementation based on it, > would go a long way towards helping folks think about other real-world > implementation of XCP. And, it seems likely to me that both BSD and > the 7200 are well positioned to act as motivators and verifiers of > such a model and its initial implementation. > > Again, just a couple of thoughts triggered by Aaron and Ted's msgs. My > apologies if this is stuff that someone else has already worked out in > some place that I should have known about but didn't.. > > cheers, > john From falk at ISI.EDU Fri Mar 19 15:02:13 2004 From: falk at ISI.EDU (Aaron Falk) Date: Fri Mar 19 15:02:56 2004 Subject: [xcp] Re: XCP spec comments In-Reply-To: <200403191339.53049.yuri@isi.edu> References: <200403191339.53049.yuri@isi.edu> Message-ID: <7599B32C-79F9-11D8-BD94-000A95DBDB84@isi.edu> On Mar 19, 2004, at 1:39 PM, Yuri Pryadkin wrote: > Aaron, > > here's some small comments on the draft. Feel free to do with them > whatever > you want. ;-) > > -Yuri > > ----- > > p10. it says "The maximum value expressable in this field is > 34Tbps,...". I > believe it should be 32 (2^5) Tbps. right. my bad. > > p12. There is a nice discussion in section 4.1.1 about sending > packets. One > thing that would be useful is to give more details regarding how tcp > should > set delta_throughput. There is a nice formula with > desired_throughput, but > how do you define that? Right now, in the kernel implementation, > delta_throughput is (roughly) set to large_constant/current_rtt. > Always. I > don't think this is the way it's supposed to be done, please correct > me. We discussed this issue and it's really up to the sender what to use. My proposal (in the spec) is to pick the speed of the local interface, i.e., the upper bound of the rate. Ted (who wrote that part of the code) chose infinity. My suggestion is to go with the spec. I don't think Ted will resist. > > p14. Processing feedback at the sender. In the formula for cwnd > feedback is > multiplied by rtt (it says current rtt), yet, the feedback may have > been > calculated by routers for a different rtt. Is it a problem when rtt > can > rapidly change? An alternative would be to have reverse_rtt in the xcp > header. The router wants the sender to adjust its sending rate by some value, this should be converted to cwnd using the most recent estimate of RTT. If the sender's RTT is rapidly changing there will probably be some instability but I think that we can't do much about that. (It would certainly be unstable for TCP, too.) > > p16. Pseudo-code for packet arrival. It seems that we're computing > sum_rtt_by_throughput for the sole purpose of calculating a weighted > average > of rtt (weighted by pkt_size/throughput). I wonder if there's a > cheaper way > to calculate those. My concern is that (depending on what precision > you want > to have) even 64 bit integers can overflow for those values. > Especially if a > lot of packets are processed in a (relatively) large control interval. > If > control interval is large, it means that rtt is likely to be large, and > 1/throughput is stored in an int64 as LARGENUMBER/throughput, so > 1/throughput > can also be large. So, it's a real possibility that we'll have to > emulate FP > for this parameter. > OK. > p17. I think it would be useful to give bounds (intervals) on F, Cp, > and Cn. > Could you take a stab at what those should be? > p21. Pseudocode at the end of the page. It seems that one line is > missing: > 37.5 min_queue = inst_queue Yes, you are correct. > Aso, in line 38 you use MAX_QUEUE, but in fact you mean MIN_QUEUE (or, > perhaps, you do mean MAX_QUEUE, but then max() should be changed to > min()?) No, I think the code is correct. MAX_QUEUE is the maximum standing queue you want to operate at, not the maximum capacity of the buffer. Line 38 sets the timer so that it gets longer if the standing queue is longer (than MAX_QUEUE). Perhaps MAX_QUEUE should be renamed to MAX_MIN_QUEUE or DESIRED_STANDING_QUEUE. --aaron -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://gamma.isi.edu/pipermail/xcp/attachments/20040319/7e81131a/PGP.bin From mjendel_yamen at yahoo.fr Tue Mar 30 01:57:12 2004 From: mjendel_yamen at yahoo.fr (=?iso-8859-1?q?mjendel=20yamen?=) Date: Tue Mar 30 01:57:20 2004 Subject: [xcp] I need an urgent help please Message-ID: <20040330095712.79934.qmail@web42004.mail.yahoo.com> I'm a new ns-user, and there are still many things I want to learn in ns. I am working with VoIP protocols as ; H323, SIP MGCP...in ns2 and i have problems with VoIP application. Could anyone tell me how to implement those protocols in ns2, or may be some source or links I can visit to learn implementing VoIP protocols in ns2 ? Thanks, Best regards --------------------------------- Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout ! Cr?ez votre Yahoo! Mail Dialoguez en direct avec vos amis gr?ce ? Yahoo! Messenger ! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://gamma.isi.edu/pipermail/xcp/attachments/20040330/63d7b357/attachment.html From ysch0i at ieee.org Tue Mar 30 07:22:54 2004 From: ysch0i at ieee.org (Young S. Choi) Date: Tue Mar 30 07:24:00 2004 Subject: [xcp] Kernel Ticks & its limits Message-ID: <200701c4166a$e1f15310$d50ee69b@younghhqmj7atr> Hi. Maybe it is not a right mailing list. Sorry about that. but I need kernel ticks and its maximum(possible) limits in Highspeed network environment. As far as I know, current BSD OS use timer ticks are 100ms, 200ms, 500ms for TCP(might be wrong but hundreds ms order right?) And I heard that traditionl BSDs use protocol-level sotware timers with 200ms and 500ms intervals. BUT recent BSDs do not use these fixed time invervals. If I implement some kinds of packet shaper or scheduler It would need *very* fine grained timer. My Question is... Current kernel timer granularity???(for FreeBSD?, BSD, Solaris, Linux, etc...) And what is the minimum or acceptable(I mean implementable) timer granularity(If I hack kernel) for Gigabit network? From falk at ISI.EDU Tue Mar 30 07:53:17 2004 From: falk at ISI.EDU (Aaron Falk) Date: Tue Mar 30 07:54:01 2004 Subject: [xcp] I need an urgent help please In-Reply-To: <20040330095712.79934.qmail@web42004.mail.yahoo.com> References: <20040330095712.79934.qmail@web42004.mail.yahoo.com> Message-ID: <5C4C36DE-8262-11D8-B686-000A95DBDB84@isi.edu> This is the wrong list for your question. See http://www.isi.edu/nsnam/ns/ for information on the ns-users mailing list. --aaron On Mar 30, 2004, at 1:57 AM, mjendel yamen wrote: > I'm a new ns-user, and there are still many things I want to learn in > ns. > I am working with VoIP protocols as ; H323, SIP MGCP...in ns2 and i > have problems with VoIP application.?Could anyone tell me how to > implement those protocols in ns2, or may be some source? or links I > can visit to learn implementing VoIP protocols in ns2? ? > Thanks, > Best regards > > Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout > ! > Cr?ez votre Yahoo! Mail > > Dialoguez en direct avec vos amis gr?ce ? Yahoo! Messenger > !_______________________________________________ > xcp mailing list > xcp@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/xcp -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://gamma.isi.edu/pipermail/xcp/attachments/20040330/e763acac/PGP.bin From faber at ISI.EDU Tue Mar 30 13:16:20 2004 From: faber at ISI.EDU (Ted Faber) Date: Tue Mar 30 13:16:48 2004 Subject: [xcp] Kernel Ticks & its limits In-Reply-To: <200701c4166a$e1f15310$d50ee69b@younghhqmj7atr> References: <200701c4166a$e1f15310$d50ee69b@younghhqmj7atr> Message-ID: <20040330211620.GA30410@pun.isi.edu> On Wed, Mar 31, 2004 at 12:22:54AM +0900, Young S. Choi wrote: > Hi. > > Maybe it is not a right mailing list. Sorry about that. but I need kernel > ticks and its maximum(possible) limits in Highspeed network environment. It's not. FreeBSD.org has a search function for its mailing lists there and the toipic has been discussed. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://gamma.isi.edu/pipermail/xcp/attachments/20040330/30372b77/attachment.bin