All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesus Sanchez-Palencia <jesus.sanchez-palencia@intel.com>
To: Richard Cochran <richardcochran@gmail.com>
Cc: netdev@vger.kernel.org, jhs@mojatatu.com,
	xiyou.wangcong@gmail.com, jiri@resnulli.us,
	vinicius.gomes@intel.com, intel-wired-lan@lists.osuosl.org,
	anna-maria@linutronix.de, henrik@austad.us, tglx@linutronix.de,
	john.stultz@linaro.org, andre.guedes@intel.com,
	ivan.briano@intel.com, levi.pearson@harman.com
Subject: Re: [RFC v2 net-next 00/10] Time based packet transmission
Date: Tue, 23 Jan 2018 10:07:23 -0800	[thread overview]
Message-ID: <3977fbe2-0e96-25c2-1ade-afe1300119ce@intel.com> (raw)
In-Reply-To: <20180123052601.oqrh3cnwfpoxmsdg@localhost>

Hi,


On 01/22/2018 09:26 PM, Richard Cochran wrote:
> On Mon, Jan 22, 2018 at 09:23:27PM -0800, Richard Cochran wrote:
>> On Wed, Jan 17, 2018 at 03:06:11PM -0800, Jesus Sanchez-Palencia wrote:
>>> First, a baseline test was ran for 10 minutes with the plain kernel only:
>>>
>>> |                 | plain kernel @ 1ms |
>>> |-----------------+--------------------+
>>> | min (ns):       |    +4.820000e+02   |
>>> | max (ns):       |    +9.999300e+05   |
>>> | pk-pk:          |    +9.994480e+05   |
>>
>> ...
>>
>>> |                 |    tbs SW @ 1ms   |  tbs HW @ 1ms  | tbs HW @ 250 us |
>>> |-----------------+-------------------+----------------+-----------------|
>>> | min (ns):       |    +1.510000e+02  |  +4.420000e+02 |   +4.260000e+02 |
>>> | max (ns):       |    +9.977030e+05  |  +5.060000e+02 |   +5.060000e+02 |
>>> | pk-pk:          |    +9.975520e+05  |  +6.400000e+01 |   +8.000000e+01 |
>>
>> I wonder about these worst case measurements of 999 and 998
>> milliseconds.  It almost looks like you missed one entire period.
>   ^^^^
> microseconds
> 
>> Could this simply be a bug in the test setup?


Yes. From the data set of the tbs SW:

offset |      timestamp
-------+---------------------
(...)  |
10639  | 1516117448.058010639
9503   | 1516117448.059009503
10167  | 1516117448.060010167
9823   | 1516117448.061009823
9567   | 1516117448.062009567
997703 | 1516117448.062997703 ****
911719 | 1516117448.063911719
12655  | 1516117448.065012655
12399  | 1516117448.066012399
(...)

Since the period was 1ms, the highlighted entry should have arrived within the
[1516117448.063000000, 1516117448.063999999] range, so in this case it was
early. For the next runs, I will modify the test setup so the txtime is sent as
part of the packet payload and later taken into account by the post-processing
script that is calculating the offsets.


Thanks,
Jesus


>>
>> Thanks,
>> Richard

WARNING: multiple messages have this Message-ID (diff)
From: Jesus Sanchez-Palencia <jesus.sanchez-palencia@intel.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [RFC v2 net-next 00/10] Time based packet transmission
Date: Tue, 23 Jan 2018 10:07:23 -0800	[thread overview]
Message-ID: <3977fbe2-0e96-25c2-1ade-afe1300119ce@intel.com> (raw)
In-Reply-To: <20180123052601.oqrh3cnwfpoxmsdg@localhost>

Hi,


On 01/22/2018 09:26 PM, Richard Cochran wrote:
> On Mon, Jan 22, 2018 at 09:23:27PM -0800, Richard Cochran wrote:
>> On Wed, Jan 17, 2018 at 03:06:11PM -0800, Jesus Sanchez-Palencia wrote:
>>> First, a baseline test was ran for 10 minutes with the plain kernel only:
>>>
>>> |                 | plain kernel @ 1ms |
>>> |-----------------+--------------------+
>>> | min (ns):       |    +4.820000e+02   |
>>> | max (ns):       |    +9.999300e+05   |
>>> | pk-pk:          |    +9.994480e+05   |
>>
>> ...
>>
>>> |                 |    tbs SW @ 1ms   |  tbs HW @ 1ms  | tbs HW @ 250 us |
>>> |-----------------+-------------------+----------------+-----------------|
>>> | min (ns):       |    +1.510000e+02  |  +4.420000e+02 |   +4.260000e+02 |
>>> | max (ns):       |    +9.977030e+05  |  +5.060000e+02 |   +5.060000e+02 |
>>> | pk-pk:          |    +9.975520e+05  |  +6.400000e+01 |   +8.000000e+01 |
>>
>> I wonder about these worst case measurements of 999 and 998
>> milliseconds.  It almost looks like you missed one entire period.
>   ^^^^
> microseconds
> 
>> Could this simply be a bug in the test setup?


Yes. From the data set of the tbs SW:

offset |      timestamp
-------+---------------------
(...)  |
10639  | 1516117448.058010639
9503   | 1516117448.059009503
10167  | 1516117448.060010167
9823   | 1516117448.061009823
9567   | 1516117448.062009567
997703 | 1516117448.062997703 ****
911719 | 1516117448.063911719
12655  | 1516117448.065012655
12399  | 1516117448.066012399
(...)

Since the period was 1ms, the highlighted entry should have arrived within the
[1516117448.063000000, 1516117448.063999999] range, so in this case it was
early. For the next runs, I will modify the test setup so the txtime is sent as
part of the packet payload and later taken into account by the post-processing
script that is calculating the offsets.


Thanks,
Jesus


>>
>> Thanks,
>> Richard

  reply	other threads:[~2018-01-23 18:08 UTC|newest]

Thread overview: 86+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-17 23:06 [RFC v2 net-next 00/10] Time based packet transmission Jesus Sanchez-Palencia
2018-01-17 23:06 ` [Intel-wired-lan] " Jesus Sanchez-Palencia
2018-01-17 23:06 ` [RFC v2 net-next 01/10] net: Add a new socket option for a future transmit time Jesus Sanchez-Palencia
2018-01-17 23:06   ` [Intel-wired-lan] " Jesus Sanchez-Palencia
2018-01-18  8:42   ` Miroslav Lichvar
2018-01-18  8:42     ` Miroslav Lichvar
2018-01-18 17:13     ` Richard Cochran
2018-01-18 17:13       ` Richard Cochran
2018-02-01  0:49       ` Jesus Sanchez-Palencia
2018-02-01  0:49         ` Jesus Sanchez-Palencia
2018-02-01  4:16         ` Richard Cochran
2018-02-01  4:16           ` Richard Cochran
2018-02-01  9:27         ` Miroslav Lichvar
2018-02-01  9:27           ` Miroslav Lichvar
2018-02-01 20:55           ` Jesus Sanchez-Palencia
2018-02-01 20:55             ` Jesus Sanchez-Palencia
2018-01-23 21:22     ` Vinicius Costa Gomes
2018-01-23 21:22       ` Vinicius Costa Gomes
2018-01-24  3:04       ` Richard Cochran
2018-01-24  3:04         ` Richard Cochran
2018-01-24 22:46         ` Vinicius Costa Gomes
2018-01-24 22:46           ` Vinicius Costa Gomes
2018-01-26  2:12           ` Richard Cochran
2018-01-26  2:12             ` Richard Cochran
2018-02-12 22:39     ` Jesus Sanchez-Palencia
2018-02-12 22:39       ` Jesus Sanchez-Palencia
2018-02-13  9:56       ` Miroslav Lichvar
2018-02-13  9:56         ` Miroslav Lichvar
2018-01-18 17:11   ` Richard Cochran
2018-01-18 17:11     ` [Intel-wired-lan] " Richard Cochran
2018-01-23 18:12     ` Jesus Sanchez-Palencia
2018-01-23 18:12       ` [Intel-wired-lan] " Jesus Sanchez-Palencia
2018-01-19 21:15   ` Willem de Bruijn
2018-01-19 21:15     ` [Intel-wired-lan] " Willem de Bruijn
2018-01-20  2:09     ` Richard Cochran
2018-01-20  2:09       ` [Intel-wired-lan] " Richard Cochran
2018-01-25  9:12       ` Miroslav Lichvar
2018-01-25  9:12         ` Miroslav Lichvar
2018-01-25 16:52         ` Richard Cochran
2018-01-25 16:52           ` Richard Cochran
2018-01-23 18:24     ` Jesus Sanchez-Palencia
2018-01-23 18:24       ` [Intel-wired-lan] " Jesus Sanchez-Palencia
2018-01-23 20:02       ` Willem de Bruijn
2018-01-23 20:02         ` [Intel-wired-lan] " Willem de Bruijn
2018-01-17 23:06 ` [RFC v2 net-next 02/10] net: ipv4: raw: Hook into time based transmission Jesus Sanchez-Palencia
2018-01-17 23:06   ` [Intel-wired-lan] " Jesus Sanchez-Palencia
2018-01-18  0:28   ` Eric Dumazet
2018-01-18  0:28     ` [Intel-wired-lan] " Eric Dumazet
2018-01-17 23:06 ` [RFC v2 net-next 03/10] net: ipv4: udp: " Jesus Sanchez-Palencia
2018-01-17 23:06   ` [Intel-wired-lan] " Jesus Sanchez-Palencia
2018-01-17 23:06 ` [RFC v2 net-next 04/10] net: packet: " Jesus Sanchez-Palencia
2018-01-17 23:06   ` [Intel-wired-lan] " Jesus Sanchez-Palencia
2018-01-17 23:06 ` [RFC v2 net-next 05/10] net/sched: Allow creating a Qdisc watchdog with other clocks Jesus Sanchez-Palencia
2018-01-17 23:06   ` [Intel-wired-lan] " Jesus Sanchez-Palencia
2018-01-17 23:06 ` [RFC v2 net-next 06/10] net/sched: Introduce the TBS Qdisc Jesus Sanchez-Palencia
2018-01-17 23:06   ` [Intel-wired-lan] " Jesus Sanchez-Palencia
2018-01-18 13:35   ` Jamal Hadi Salim
2018-01-18 13:35     ` [Intel-wired-lan] " Jamal Hadi Salim
2018-01-18 13:44     ` Jamal Hadi Salim
2018-01-18 13:44       ` [Intel-wired-lan] " Jamal Hadi Salim
2018-01-23 21:45       ` Jesus Sanchez-Palencia
2018-01-23 21:45         ` [Intel-wired-lan] " Jesus Sanchez-Palencia
2018-01-18 17:18     ` Richard Cochran
2018-01-18 17:18       ` [Intel-wired-lan] " Richard Cochran
2018-01-23 22:01     ` Jesus Sanchez-Palencia
2018-01-23 22:01       ` [Intel-wired-lan] " Jesus Sanchez-Palencia
2018-01-19 21:18   ` Willem de Bruijn
2018-01-19 21:18     ` [Intel-wired-lan] " Willem de Bruijn
2018-01-17 23:06 ` [RFC v2 net-next 07/10] igb: Refactor igb_configure_cbs() Jesus Sanchez-Palencia
2018-01-17 23:06   ` [Intel-wired-lan] " Jesus Sanchez-Palencia
2018-01-17 23:06 ` [RFC v2 net-next 08/10] igb: Only change Tx arbitration when CBS is on Jesus Sanchez-Palencia
2018-01-17 23:06   ` [Intel-wired-lan] " Jesus Sanchez-Palencia
2018-01-17 23:06 ` [RFC v2 net-next 09/10] igb: Refactor igb_offload_cbs() Jesus Sanchez-Palencia
2018-01-17 23:06   ` [Intel-wired-lan] " Jesus Sanchez-Palencia
2018-01-17 23:06 ` [RFC v2 net-next 10/10] igb: Add support for TBS offload Jesus Sanchez-Palencia
2018-01-17 23:06   ` [Intel-wired-lan] " Jesus Sanchez-Palencia
2018-01-23  5:23 ` [RFC v2 net-next 00/10] Time based packet transmission Richard Cochran
2018-01-23  5:23   ` [Intel-wired-lan] " Richard Cochran
2018-01-23  5:26   ` Richard Cochran
2018-01-23  5:26     ` [Intel-wired-lan] " Richard Cochran
2018-01-23 18:07     ` Jesus Sanchez-Palencia [this message]
2018-01-23 18:07       ` Jesus Sanchez-Palencia
2018-01-24  1:43 ` Levi Pearson
2018-01-24  1:43   ` [Intel-wired-lan] " Levi Pearson
2018-01-27  0:04   ` Jesus Sanchez-Palencia
2018-01-27  0:04     ` [Intel-wired-lan] " Jesus Sanchez-Palencia

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3977fbe2-0e96-25c2-1ade-afe1300119ce@intel.com \
    --to=jesus.sanchez-palencia@intel.com \
    --cc=andre.guedes@intel.com \
    --cc=anna-maria@linutronix.de \
    --cc=henrik@austad.us \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=ivan.briano@intel.com \
    --cc=jhs@mojatatu.com \
    --cc=jiri@resnulli.us \
    --cc=john.stultz@linaro.org \
    --cc=levi.pearson@harman.com \
    --cc=netdev@vger.kernel.org \
    --cc=richardcochran@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=vinicius.gomes@intel.com \
    --cc=xiyou.wangcong@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.