| What do we have a mailing list for? :-)
I hope this reaches everyone, except I know that it doesn’t reach Francesco…
Begin forwarded message:
Subject: Re: measuring delta t
Date: January 31, 2018 at 5:18:26 AM GMT+1
Status: (please forward to the guys, I don't have their email handy right now) * section 1 and 2 and related work revised (for michael, in section 2 I have accommodated most of your issues but not all, see inside whether the patches are OK or not). Also OK with conclusions (a bit agressive but... OK :) and OK with section 3. MISSING: * section 2, end: integrated table with actions - please provide also (smaller!) table with events and (compact table with) update functions; * revisions of sections 4 and 5. * addition to XFSM tables at the end - do not seem to compile... * Salvatore's review of related work (and addition of a few HW references, e.g. programmable schedulers, calendars, etc) * all missing plots!! * improved editing of the SYN-proxy case * shorteninG!!! (most likely the not strictly essential section about the editor might be suppressed if we have space problems as it seems...) Since I'm probably not going to wake up early given the time right now, and since I'm locked up from 1 PM to 6 PM (in theory!! In practice I'll escape...), I'd give the coordination to Michael. Please further coordinate with him. I'll start at around 5 or max 6 PM, and will take control since then and until finished, probably late night. It goes without saying that the goal is to have EVERYTHING by that time, so that I can work on just finalization. I'm usually pretty good in lossless compression, so if the paper exceeds by 1 or 1.5 pages, don't worry. (but if you are longer than that, you have to worry as compression will have do became lossy...) LAST MILE, KEEP UP with the pacing!! We are almost there! Thanks Giuseppe. Francesco Gringoli <
" class="">
> ha scritto: Giuseppe,
I was editing the text. Regarding section 5.1 "Stand-alone evaluation”, results I collected so far come from software that I wrote _outiside_ the XFSM executor. I think it is fine for demonstrating the limits. However the granularity test I repeated today with the native timers from ODP-DPDK suggest that we should switch to a spin-lock implementation. While the current XFSM executor (and its description in section 4.2 "high speed SW implementation”) is using ODP timers. I will attach some figures and text later.
-Francesco
On 28 Jan 2018, at 17:04, Giuseppe Bianchi <
" class="">
> wrote:
Francesco, ottimo!
Se ce la fai oltre ai grafici e numeri prova a buttar giu' qualche riga/item anche al volo e in italiano, cosi' domani vediamo come si integrano col resto, ed in generale a che punto stiamo...
Ciao, G
Francesco Gringoli <
" class="">
> ha scritto:
Hello,
(message 2/2)
experiment with back-to-back packet. I transmitted 100000 packets with 1470B in the UDP payload towards another machine on a 10Gb/s ethernet link. I verified all packets were received and I counted the total time for transmitting the sequence. At such datarate the time for transmitting the packet is 1228ns (**)
- spinlock: I tried decreasing the pacing and I started observing errors for \Delta = 1280ns, the system was reporting sending errors, probably because the output buffer was full. The average experiment time was 128000012ns, this makes
TH = 100000 * (8 + 14 + 12 +1470 + 8 + 20 + 4) * 8 / (128000012e-9) = 9.6Gb/s
SUPERNICE!
- DPDK: here it was not possible to schedule delays shorter than 10000ns, as soon as I start doing this the system reports EARLY delay and stops. For the sake of clarity I am not using a single delay but a list of absolute delay and I’m replacing elements as the corresponding packet is transmitted. I can try checking better how to solve this problem but I will be busy at a company tomorrow (I’m leaving now).
-Francesco
** tx_time = 8 * [8(PHYHEADER) + 14(ETHERNET HEADER) + 20(IP HEADER) + 8(UDP HEADER) + 1470(PAYLOAD) + 4(FCS) + 12(IFG)] / 10e9 = 1228ns
.
On 27 Jan 2018, at 10:00, Michael Welzl <
" class="">
> wrote:
Great!
On Jan 27, 2018, at 9:55 AM, Francesco Gringoli <
" class="">
<
" class="">mailto:
>> wrote:
Ok, I will take care of that. In the meanwhile I finished implementing the test with DPDK timers, details later on today.
For now take a look to the comparison between DPDK timers and spinlock. I tested two values of delta, 10 and 100 us. Then I removed outliers (in each experiment there are two to three points completely outside ranges), and subtracted the target delta.
Interestingly DPDK implementation seems better… But I want to repeat the test with SPINlock as I’m using a two weeks old dataset.
Bottom line: DPDK timers seem promising.
-Francesco
<comparison.pdf>
On 26 Jan 2018, at 15:38, Giuseppe bianchi <
" class="">
<
" class="">mailto:
>> wrote:
Very goog.
And yes not only small delta t but also a crash test to understand how much can you push in the minimal delay would be great... probably to clearly show this "crash test" a different (additional) plot is needed though which shows when a too small delta-t becomes a "0"i.e. back to back packets.
For dpdk sure!
likely short - sent from mobile
Il 26 Gennaio 2018 12:10:39 CET, Michael Welzl <
" class="">
<
" class="">mailto:
>> ha scritto:
Hi,
Great, I think!
On Jan 26, 2018, at 12:01 PM, Francesco Gringoli <
" class="">
<
" class="">mailto:
>> wrote:
Hi everybody,
I ran an experiment where I change the delay between packets following an exponential decreasing sequence, i.e., start from 100ms I divide by 2 for 10 samples down to 195us, then I repeat in a loop for 1000 times.
The first attempt was with spinlocks using ODP-DPDK. I attach the standard matlab boxplot. In x-axis the scheduled delay in ms, in y-axis the distance from the expected delay. The first sample on the left is for the highest delay.
First: we see that the scheduling is accurate. The median distance is below 1us as well the 75th percentile of the points. Also the whiskers are close to 1us. What I do not explain is why the boxplot is not centered in the 0 for higher delays. The worst outlier was for 1.5625ms and is below 4us.
“What I do not explain” => you mean, you can’t explain?
In this case I’d remove the 100 and 50 ms datapoints :-) they’re perhaps simply not very interesting anyway.
Two possible evolutions:
1) extend for smaller delays (the smallest now is 195us;
Yes, I think it’s necessary to know where it becomes inaccurate - to see how far we can take it, and not only show good results.
2) produce a similar figure but using DPDK timers.
This also sounds good to me - I hope Giuseppe has opinions though…
Perhaps it could be good to do a calculation of a possible sending rate with the delay (stably sending 1500 byte packets with a pacing delay of A means that you send at a rate of B => you could add values for B on the x axis to make this easier to understand?!)
Cheers,
Michael
— —
Francesco Gringoli, PhD
Assistant Professor
Dept. of Information Engineering
University of Brescia
via Branze, 38
25123 Brescia
ITALY
Ph: ++39.030.3715843
FAX: ++39.030.380014
WWW: http://netweb.ing.unibs.it/~gringoli <http://netweb.ing.unibs.it/~gringoli>
— —
Francesco Gringoli, PhD
Assistant Professor
Dept. of Information Engineering
University of Brescia
via Branze, 38
25123 Brescia
ITALY
Ph: ++39.030.3715843
FAX: ++39.030.380014
WWW: http://netweb.ing.unibs.it/~gringoli
— —
Francesco Gringoli, PhD
Assistant Professor
Dept. of Information Engineering
University of Brescia
via Branze, 38
25123 Brescia
ITALY
Ph: ++39.030.3715843
FAX: ++39.030.380014
WWW: http://netweb.ing.unibs.it/~gringoli
|