Discussion:
[gem5-dev] Review Request: TrafficGen: Add a basic traffic generator
(too old to reply)
Andreas Hansson
2012-08-24 18:20:31 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1368/
-----------------------------------------------------------

Review request for Default.


Description
-------

Changeset 9170:bfab7266331f
---------------------------
TrafficGen: Add a basic traffic generator

This patch adds a traffic generator to the code base. The generator is
aimed to be used as a black box model to create appropriate use-cases
and benchmarks for the memory system, and in particular the
interconnect and the memory controller.

The traffic generator is a master module, where the actual behaviour
is captured in a state-transition graph where each state generates
some sort of traffic. By constructing a graph it is possible to create
very elaborate scenarios from basic generators. Currencly the set of
generators include idling, linear address sweeps, random address
sequences and playback of traces (recording will be done by the
Communication Monitor in a follow-up patch). At the moment the graph
and the states are described in an ad-hoc line-based format, and in
the future this should be aligned with our used of e.g. the Google
protobufs. Similarly for the traces, the format is currently a
simplistic ad-hoc line-based format that merely serves as a starting
point.

In addition to being used as a black-box model for system components,
the traffic generator is also useful for creating test cases and
regressions for the interconnect and memory system. In future patches
we will use the traffic generator to create DRAM test cases for the
controller model.

The patch following this one adds a basic regressions which also
contains an example configuration script and trace file for playback.


Diffs
-----

src/mem/SConscript 1d983855df2c
src/mem/TrafficGen.py PRE-CREATION
src/mem/traffic_gen.hh PRE-CREATION
src/mem/traffic_gen.cc PRE-CREATION

Diff: http://reviews.gem5.org/r/1368/diff/


Testing
-------

util/regress all passing (disregarding t1000 and eio)


Thanks,

Andreas Hansson
nathan binkert
2012-08-24 18:45:52 UTC
Permalink
How is this different from the stuff in src/cpu/testers? And
shouldn't this go in src/cpu/testers?

Nate

On Fri, Aug 24, 2012 at 11:20 AM, Andreas Hansson
Post by Andreas Hansson
-----------------------------------------------------------
http://reviews.gem5.org/r/1368/
-----------------------------------------------------------
Review request for Default.
Description
-------
Changeset 9170:bfab7266331f
---------------------------
TrafficGen: Add a basic traffic generator
This patch adds a traffic generator to the code base. The generator is
aimed to be used as a black box model to create appropriate use-cases
and benchmarks for the memory system, and in particular the
interconnect and the memory controller.
The traffic generator is a master module, where the actual behaviour
is captured in a state-transition graph where each state generates
some sort of traffic. By constructing a graph it is possible to create
very elaborate scenarios from basic generators. Currencly the set of
generators include idling, linear address sweeps, random address
sequences and playback of traces (recording will be done by the
Communication Monitor in a follow-up patch). At the moment the graph
and the states are described in an ad-hoc line-based format, and in
the future this should be aligned with our used of e.g. the Google
protobufs. Similarly for the traces, the format is currently a
simplistic ad-hoc line-based format that merely serves as a starting
point.
In addition to being used as a black-box model for system components,
the traffic generator is also useful for creating test cases and
regressions for the interconnect and memory system. In future patches
we will use the traffic generator to create DRAM test cases for the
controller model.
The patch following this one adds a basic regressions which also
contains an example configuration script and trace file for playback.
Diffs
-----
src/mem/SConscript 1d983855df2c
src/mem/TrafficGen.py PRE-CREATION
src/mem/traffic_gen.hh PRE-CREATION
src/mem/traffic_gen.cc PRE-CREATION
Diff: http://reviews.gem5.org/r/1368/diff/
Testing
-------
util/regress all passing (disregarding t1000 and eio)
Thanks,
Andreas Hansson
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
Andreas Hansson
2012-08-24 18:52:16 UTC
Permalink
Hi Nate,

It is not a tester, it is a stimuli generator for the memory system. That said, I am happy to move it if that makes more sense. (We are using it to create regressions for the memory controller though, but that is simply because it is the easiest way to generate traffic.)

There is nothing (as far as I know) that currently can simply generate "traffic" with the kind of patterns that are useful for studying interconnect and memory controller behaviour.

Input is welcome.

Andreas


-----Original Message-----
From: binkert-***@public.gmane.org [mailto:binkert-***@public.gmane.org] On Behalf Of nathan binkert
Sent: 24 August 2012 19:46
To: gem5 Developer List
Cc: Andreas Hansson
Subject: Re: [gem5-dev] Review Request: TrafficGen: Add a basic traffic generator

How is this different from the stuff in src/cpu/testers? And
shouldn't this go in src/cpu/testers?

Nate

On Fri, Aug 24, 2012 at 11:20 AM, Andreas Hansson
Post by Andreas Hansson
-----------------------------------------------------------
http://reviews.gem5.org/r/1368/
-----------------------------------------------------------
Review request for Default.
Description
-------
Changeset 9170:bfab7266331f
---------------------------
TrafficGen: Add a basic traffic generator
This patch adds a traffic generator to the code base. The generator is
aimed to be used as a black box model to create appropriate use-cases
and benchmarks for the memory system, and in particular the
interconnect and the memory controller.
The traffic generator is a master module, where the actual behaviour
is captured in a state-transition graph where each state generates
some sort of traffic. By constructing a graph it is possible to create
very elaborate scenarios from basic generators. Currencly the set of
generators include idling, linear address sweeps, random address
sequences and playback of traces (recording will be done by the
Communication Monitor in a follow-up patch). At the moment the graph
and the states are described in an ad-hoc line-based format, and in
the future this should be aligned with our used of e.g. the Google
protobufs. Similarly for the traces, the format is currently a
simplistic ad-hoc line-based format that merely serves as a starting
point.
In addition to being used as a black-box model for system components,
the traffic generator is also useful for creating test cases and
regressions for the interconnect and memory system. In future patches
we will use the traffic generator to create DRAM test cases for the
controller model.
The patch following this one adds a basic regressions which also
contains an example configuration script and trace file for playback.
Diffs
-----
src/mem/SConscript 1d983855df2c
src/mem/TrafficGen.py PRE-CREATION
src/mem/traffic_gen.hh PRE-CREATION
src/mem/traffic_gen.cc PRE-CREATION
Diff: http://reviews.gem5.org/r/1368/diff/
Testing
-------
util/regress all passing (disregarding t1000 and eio)
Thanks,
Andreas Hansson
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Nilay Vaish
2012-08-24 18:56:49 UTC
Permalink
Andreas, you need to checkout the network tester in
src/cpu/testers/networktest directory.

--
Nilay
Post by Andreas Hansson
Hi Nate,
It is not a tester, it is a stimuli generator for the memory system. That said, I am happy to move it if that makes more sense. (We are using it to create regressions for the memory controller though, but that is simply because it is the easiest way to generate traffic.)
There is nothing (as far as I know) that currently can simply generate "traffic" with the kind of patterns that are useful for studying interconnect and memory controller behaviour.
Input is welcome.
Andreas
-----Original Message-----
Sent: 24 August 2012 19:46
To: gem5 Developer List
Cc: Andreas Hansson
Subject: Re: [gem5-dev] Review Request: TrafficGen: Add a basic traffic generator
How is this different from the stuff in src/cpu/testers? And
shouldn't this go in src/cpu/testers?
Nate
Andreas Hansson
2012-08-24 20:39:06 UTC
Permalink
Hi Nilay,

How does the network tester relate to the traffic gen? I do not see how
there is any possibility to use it for the use-cases that are captured by
the traffic gen. Could you explain what you were referring to?

Andreas
Post by Nilay Vaish
Andreas, you need to checkout the network tester in
src/cpu/testers/networktest directory.
--
Nilay
Post by Andreas Hansson
Hi Nate,
It is not a tester, it is a stimuli generator for the memory system.
That said, I am happy to move it if that makes more sense. (We are using
it to create regressions for the memory controller though, but that is
simply because it is the easiest way to generate traffic.)
There is nothing (as far as I know) that currently can simply generate
"traffic" with the kind of patterns that are useful for studying
interconnect and memory controller behaviour.
Input is welcome.
Andreas
-----Original Message-----
binkert
Sent: 24 August 2012 19:46
To: gem5 Developer List
Cc: Andreas Hansson
Subject: Re: [gem5-dev] Review Request: TrafficGen: Add a basic traffic generator
How is this different from the stuff in src/cpu/testers? And
shouldn't this go in src/cpu/testers?
Nate
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Nilay Vaish
2012-08-24 20:53:49 UTC
Permalink
The network tester generates traffic so that Ruby's network components can
be tested. Just like the CPU models are agnostic of the memory system in
place, it seems that any traffic generator for testing the interconnect
can be independent of the memory system. In fact, other Ruby testers might
also be relevant for the classic memory system.

--
Nilay
Post by Andreas Hansson
Hi Nilay,
How does the network tester relate to the traffic gen? I do not see how
there is any possibility to use it for the use-cases that are captured by
the traffic gen. Could you explain what you were referring to?
Andreas
Post by Nilay Vaish
Andreas, you need to checkout the network tester in
src/cpu/testers/networktest directory.
--
Nilay
Post by Andreas Hansson
Hi Nate,
It is not a tester, it is a stimuli generator for the memory system.
That said, I am happy to move it if that makes more sense. (We are using
it to create regressions for the memory controller though, but that is
simply because it is the easiest way to generate traffic.)
There is nothing (as far as I know) that currently can simply generate
"traffic" with the kind of patterns that are useful for studying
interconnect and memory controller behaviour.
Input is welcome.
Andreas
-----Original Message-----
binkert
Sent: 24 August 2012 19:46
To: gem5 Developer List
Cc: Andreas Hansson
Subject: Re: [gem5-dev] Review Request: TrafficGen: Add a basic traffic generator
How is this different from the stuff in src/cpu/testers? And
shouldn't this go in src/cpu/testers?
Nate
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
Andreas Hansson
2012-08-24 21:13:42 UTC
Permalink
Hi Nilay,

Thanks for the clarification. I am sure these testers could be useful for
the classic memory system, but they do not provide the functionality of
the current traffic generator.

Agreed?

Andreas
Post by Nilay Vaish
The network tester generates traffic so that Ruby's network components can
be tested. Just like the CPU models are agnostic of the memory system in
place, it seems that any traffic generator for testing the interconnect
can be independent of the memory system. In fact, other Ruby testers might
also be relevant for the classic memory system.
--
Nilay
Post by Andreas Hansson
Hi Nilay,
How does the network tester relate to the traffic gen? I do not see how
there is any possibility to use it for the use-cases that are captured by
the traffic gen. Could you explain what you were referring to?
Andreas
Post by Nilay Vaish
Andreas, you need to checkout the network tester in
src/cpu/testers/networktest directory.
--
Nilay
Post by Andreas Hansson
Hi Nate,
It is not a tester, it is a stimuli generator for the memory system.
That said, I am happy to move it if that makes more sense. (We are using
it to create regressions for the memory controller though, but that is
simply because it is the easiest way to generate traffic.)
There is nothing (as far as I know) that currently can simply generate
"traffic" with the kind of patterns that are useful for studying
interconnect and memory controller behaviour.
Input is welcome.
Andreas
-----Original Message-----
binkert
Sent: 24 August 2012 19:46
To: gem5 Developer List
Cc: Andreas Hansson
Subject: Re: [gem5-dev] Review Request: TrafficGen: Add a basic
traffic
generator
How is this different from the stuff in src/cpu/testers? And
shouldn't this go in src/cpu/testers?
Nate
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy
the information in any medium. Thank you.
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Nilay Vaish
2012-08-24 21:21:57 UTC
Permalink
Post by Andreas Hansson
Hi Nilay,
Thanks for the clarification. I am sure these testers could be useful for
the classic memory system, but they do not provide the functionality of
the current traffic generator.
Agreed?
Nope, I disagree. Ruby testers do support testing with random addresses,
linear address sweeping. And I have a patch for testing with traces.

--
Nilay
Andreas Hansson
2012-08-24 21:27:43 UTC
Permalink
Hi Nilay,

Ok. Could you perhaps show how to make a traffic generator that would
create something along the lines of an HDLCD controller:

850 Mbyte/s read to a specific address range for time T1, then idling for
T2. Repeat the above.

The whole point is to mimic the traffic of real IP components that we do
not yet have models for.

I am not sure I understand how to do something like this with what is
there at the moment.

Thanks,

Andreas
Post by Nilay Vaish
Post by Andreas Hansson
Hi Nilay,
Thanks for the clarification. I am sure these testers could be useful for
the classic memory system, but they do not provide the functionality of
the current traffic generator.
Agreed?
Nope, I disagree. Ruby testers do support testing with random addresses,
linear address sweeping. And I have a patch for testing with traces.
--
Nilay
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Ali Saidi
2012-08-24 21:44:57 UTC
Permalink
There is also the added benefit of the traffic generator that a
trace can be captured with the communication monitor and replayed with
this traffic generator.

Ali

On 24.08.2012 17:27, Andreas Hansson
Post by Andreas Hansson
Hi Nilay,
Ok. Could you perhaps show how to make a
traffic generator that would
Post by Andreas Hansson
create something along the lines of an
850 Mbyte/s read to a specific address range for
time T1, then idling for
Post by Andreas Hansson
T2. Repeat the above.
The whole point is
to mimic the traffic of real IP components that we do
Post by Andreas Hansson
not yet have
models for.
Post by Andreas Hansson
I am not sure I understand how to do something like
this with what is
Post by Andreas Hansson
there at the moment.
Thanks,
Andreas
Post by Nilay Vaish
On
Hi Nilay, Thanks for
the clarification. I am sure these testers could be useful for the
classic memory system, but they do not provide the functionality of the
current traffic generator. Agreed?
Post by Andreas Hansson
Post by Nilay Vaish
Nope, I disagree. Ruby testers do
support testing with random addresses, linear address sweeping. And I
have a patch for testing with traces. -- Nilay
_______________________________________________ gem5-dev mailing list
Post by Andreas Hansson
-- IMPORTANT NOTICE: The contents of this email and any attachments
are confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy
the information in any medium. Thank you.
_______________________________________________
Post by Andreas Hansson
gem5-dev mailing
list
Post by Andreas Hansson
http://m5sim.org/mailman/listinfo/gem5-dev
Links:
------
[1] mailto:gem5-dev-1Gs4CP2/***@public.gmane.org
[2]
http://m5sim.org/mailman/listinfo/gem5-dev
nathan binkert
2012-08-24 22:28:25 UTC
Permalink
I think the concern is of having a collection of similar, but slightly
different testers. Something that focuses on doing say coherence
protocol testing is different, but it seems odd to have more than one
traffic generator that generates random traffic is not a good choice.
Can you add your functionality to the existing one or add the existing
one's functionality to yours and just delete it?

Nate

On Fri, Aug 24, 2012 at 2:27 PM, Andreas Hansson
Post by Andreas Hansson
Hi Nilay,
Ok. Could you perhaps show how to make a traffic generator that would
850 Mbyte/s read to a specific address range for time T1, then idling for
T2. Repeat the above.
The whole point is to mimic the traffic of real IP components that we do
not yet have models for.
I am not sure I understand how to do something like this with what is
there at the moment.
Thanks,
Andreas
Post by Nilay Vaish
Post by Andreas Hansson
Hi Nilay,
Thanks for the clarification. I am sure these testers could be useful for
the classic memory system, but they do not provide the functionality of
the current traffic generator.
Agreed?
Nope, I disagree. Ruby testers do support testing with random addresses,
linear address sweeping. And I have a patch for testing with traces.
--
Nilay
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
Andreas Hansson
2012-08-24 22:30:18 UTC
Permalink
I think option number two would be trivial. The new traffic generator
could easily get another state for what ever behaviour we want. I also
think the states that are already there provide a very good starting point.

If everyone agrees with this I'd be happy to transition things over to the
new traffic gen.

Andreas
Post by nathan binkert
I think the concern is of having a collection of similar, but slightly
different testers. Something that focuses on doing say coherence
protocol testing is different, but it seems odd to have more than one
traffic generator that generates random traffic is not a good choice.
Can you add your functionality to the existing one or add the existing
one's functionality to yours and just delete it?
Nate
On Fri, Aug 24, 2012 at 2:27 PM, Andreas Hansson
Post by Andreas Hansson
Hi Nilay,
Ok. Could you perhaps show how to make a traffic generator that would
850 Mbyte/s read to a specific address range for time T1, then idling for
T2. Repeat the above.
The whole point is to mimic the traffic of real IP components that we do
not yet have models for.
I am not sure I understand how to do something like this with what is
there at the moment.
Thanks,
Andreas
Post by Nilay Vaish
Post by Andreas Hansson
Hi Nilay,
Thanks for the clarification. I am sure these testers could be useful for
the classic memory system, but they do not provide the functionality of
the current traffic generator.
Agreed?
Nope, I disagree. Ruby testers do support testing with random addresses,
linear address sweeping. And I have a patch for testing with traces.
--
Nilay
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy
the information in any medium. Thank you.
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Nilay Vaish
2012-08-25 14:39:20 UTC
Permalink
Post by Andreas Hansson
Hi Nilay,
Ok. Could you perhaps show how to make a traffic generator that would
850 Mbyte/s read to a specific address range for time T1, then idling for
T2. Repeat the above.
The whole point is to mimic the traffic of real IP components that we do
not yet have models for.
I am not sure I understand how to do something like this with what is
there at the moment.
There is at least one tester in gem5 that supports specifying the rate at
which traffic is pushed in to the network.

But that said, why is it required that this particular traffic pattern
that you need should be supported in gem5? There are an infinite number of
traffic patterns that can be created. I don't think we are trying to
create something that can be used to generate any traffic pattern. The
infrastructure should be flexible enough that if some one needs a new
traffic pattern, he/she can modify the traffic generator with as less
effort as possible.

--
Nilay
Ali Saidi
2012-08-25 15:20:05 UTC
Permalink
Post by Andreas Hansson
Hi Nilay,
Ok. Could you perhaps show how to make a traffic generator that would
850 Mbyte/s read to a specific address range for time T1, then idling for
T2. Repeat the above.
The whole point is to mimic the traffic of real IP components that we do
not yet have models for.
I am not sure I understand how to do something like this with what is
there at the moment.
There is at least one tester in gem5 that supports specifying the rate at which traffic is pushed in to the network.
But that said, why is it required that this particular traffic pattern that you need should be supported in gem5? There are an infinite number of traffic patterns that can be created. I don't think we are trying to create something that can be used to generate any traffic pattern. The infrastructure should be flexible enough that if some one needs a new traffic pattern, he/she can modify the traffic generator with as less effort as possible
Hi Nilay,

I think the point that Andreas is trying to make is that traffic generators are useful for more than testing and people want to to use traffic generators to inject traffic into the systems (many systems have lots of other traffic going through them, not just CPU traffic). The traffic generator we posted lets the user specifies a configuration file that describes what kind of traffic that generator will generate. You can create infinite different configurations including one that emulates an hdlcd controller, video encoders or decoders, etc. Anyone who is interested in a client system should be interested in traffic from other components in the system and this traffic generator is a good way to produce some traffic for that purpose. It's far more configurable than the testers that currentl
y are in gem5.

The meta-question I have is, why do you care that much? It's a reasonably small piece of code that is well documented and comes with a set of regression tests. It seems like exactly the thing we want in the repository.

Thanks,

Ali
Nilay Vaish
2012-08-25 23:40:22 UTC
Permalink
Post by Andreas Hansson
Hi Nilay,
I think the point that Andreas is trying to make is that traffic
generators are useful for more than testing and people want to to use
traffic generators to inject traffic into the systems (many systems have
lots of other traffic going through them, not just CPU traffic). The
traffic generator we posted lets the user specifies a configuration file
that describes what kind of traffic that generator will generate. You
can create infinite different configurations including one that emulates
an hdlcd controller, video encoders or decoders, etc. Anyone who is
interested in a client system should be interested in traffic from other
components in the system and this traffic generator is a good way to
produce some traffic for that purpose. It's far more configurable than
the testers that currently are in gem5.
The meta-question I have is, why do you care that much? It's a
reasonably small piece of code that is well documented and comes with a
set of regression tests. It seems like exactly the thing we want in the
repository.
Since we already have some traffic generators in place, we should be
upgrading those if possible. I would prefer if we have only a single way
to generate a given type of traffic.

--
Nilay
Andreas Hansson
2012-08-26 05:45:09 UTC
Permalink
Hi Nilay,

I see your point. However, there is currently nothing in gem5 to simulate
the "non-CPU" components in a System on Chip, and that is why we are
adding this traffic generator.

The framework based on the state graphs also enables us to e.g. add a
probabilistic behaviour in terms of graph traversal, and all the "vanilla"
network patterns (that have nothing at all to do with real lifeŠuniform
random, bit reversal, tornado etc) can also be generated if anyone
strongly feels like they add any value.

I would suggest:

1) Get the new traffic generator in there. Perhaps src/mem is not the
right location, but it is definitely not a CPU or a tester, so suggestions
are welcome.

2) Progressively rebase some of the existing testers on the more generic
traffic generator.

It is also worth noting that the existing testers are cycle callable (they
tick even when there is nothing to do) and the new traffic generator is
purely event-based.

Andreas
Post by Nilay Vaish
Post by Andreas Hansson
Hi Nilay,
I think the point that Andreas is trying to make is that traffic
generators are useful for more than testing and people want to to use
traffic generators to inject traffic into the systems (many systems have
lots of other traffic going through them, not just CPU traffic). The
traffic generator we posted lets the user specifies a configuration file
that describes what kind of traffic that generator will generate. You
can create infinite different configurations including one that emulates
an hdlcd controller, video encoders or decoders, etc. Anyone who is
interested in a client system should be interested in traffic from other
components in the system and this traffic generator is a good way to
produce some traffic for that purpose. It's far more configurable than
the testers that currently are in gem5.
The meta-question I have is, why do you care that much? It's a
reasonably small piece of code that is well documented and comes with a
set of regression tests. It seems like exactly the thing we want in the
repository.
Since we already have some traffic generators in place, we should be
upgrading those if possible. I would prefer if we have only a single way
to generate a given type of traffic.
--
Nilay
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Steve Reinhardt
2012-08-26 20:44:06 UTC
Permalink
It sounds like we are generally agreeing that we should, if at all
possible, only have a single traffic generator that is configurable to
generate all the patterns we might care about (including random and
trace-based generation, but also the more complex patterns Andreas
mentioned).

Not having looked at any of the code, it sounds to me like Andreas's new
traffic generator is more general than the one we currently have. If so,
then Andreas's plan to put his tester in and gradually migrate the
functionality of other testers over, eventually deleting the other testers,
makes sense. Nilay's comment about upgrading the existing testers is also
a reasonable path that would be worth considering if Andreas had not
already written a new tester, but I think the existence of Andreas's more
general framework makes that moot.

It's clear to me that this new traffic generator/tester belongs with the
other traffic generator/memory testers that are currently under
src/cpu/testers (and src/cpu/trace for trace readers). Historically, we've
had these things under src/cpu because they're "cpu-like", i.e., bus
masters driving the system, and particularly cpu-like in the situation
where they're replaying cpu traces. Another way to look at it is that a
system almost always has to have at least one component from under src/cpu
to be doing anything interesting, and from that perspective the tester is
clearly taking the place of a "regular" cpu.

I can see where a tester that's modeling some black-box device traffic
starts to stretch that concept, and I agree that src/mem/testers is an
equally reasonable place for things like this to live. However, I think
the most important thing is that all the similar modules should be in the
same place, and I'm not convinced that src/mem/testers is enough better
to warrant moving things around. If anyone feels strongly about this, feel
free to speak up.

Steve

On Sat, Aug 25, 2012 at 10:45 PM, Andreas Hansson
Post by Andreas Hansson
Hi Nilay,
I see your point. However, there is currently nothing in gem5 to simulate
the "non-CPU" components in a System on Chip, and that is why we are
adding this traffic generator.
The framework based on the state graphs also enables us to e.g. add a
probabilistic behaviour in terms of graph traversal, and all the "vanilla"
network patterns (that have nothing at all to do with real lifeŠuniform
random, bit reversal, tornado etc) can also be generated if anyone
strongly feels like they add any value.
1) Get the new traffic generator in there. Perhaps src/mem is not the
right location, but it is definitely not a CPU or a tester, so suggestions
are welcome.
2) Progressively rebase some of the existing testers on the more generic
traffic generator.
It is also worth noting that the existing testers are cycle callable (they
tick even when there is nothing to do) and the new traffic generator is
purely event-based.
Andreas
Post by Nilay Vaish
Post by Andreas Hansson
Hi Nilay,
I think the point that Andreas is trying to make is that traffic
generators are useful for more than testing and people want to to use
traffic generators to inject traffic into the systems (many systems have
lots of other traffic going through them, not just CPU traffic). The
traffic generator we posted lets the user specifies a configuration file
that describes what kind of traffic that generator will generate. You
can create infinite different configurations including one that emulates
an hdlcd controller, video encoders or decoders, etc. Anyone who is
interested in a client system should be interested in traffic from other
components in the system and this traffic generator is a good way to
produce some traffic for that purpose. It's far more configurable than
the testers that currently are in gem5.
The meta-question I have is, why do you care that much? It's a
reasonably small piece of code that is well documented and comes with a
set of regression tests. It seems like exactly the thing we want in the
repository.
Since we already have some traffic generators in place, we should be
upgrading those if possible. I would prefer if we have only a single way
to generate a given type of traffic.
--
Nilay
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
Andreas Hansson
2012-08-28 22:31:50 UTC
Permalink
Hi everyone,

I will stick with Steve's plan and move the traffic generator to
cpu/testers and then once this version is done and dusted we can
transition the other testers into the same framework.

Assuming everyone is fine with this comments on the patch are most
welcome. I'll submit a new revision once the files are moved.

Thanks,

Andreas
Post by Steve Reinhardt
It sounds like we are generally agreeing that we should, if at all
possible, only have a single traffic generator that is configurable to
generate all the patterns we might care about (including random and
trace-based generation, but also the more complex patterns Andreas
mentioned).
Not having looked at any of the code, it sounds to me like Andreas's new
traffic generator is more general than the one we currently have. If so,
then Andreas's plan to put his tester in and gradually migrate the
functionality of other testers over, eventually deleting the other testers,
makes sense. Nilay's comment about upgrading the existing testers is also
a reasonable path that would be worth considering if Andreas had not
already written a new tester, but I think the existence of Andreas's more
general framework makes that moot.
It's clear to me that this new traffic generator/tester belongs with the
other traffic generator/memory testers that are currently under
src/cpu/testers (and src/cpu/trace for trace readers). Historically, we've
had these things under src/cpu because they're "cpu-like", i.e., bus
masters driving the system, and particularly cpu-like in the situation
where they're replaying cpu traces. Another way to look at it is that a
system almost always has to have at least one component from under src/cpu
to be doing anything interesting, and from that perspective the tester is
clearly taking the place of a "regular" cpu.
I can see where a tester that's modeling some black-box device traffic
starts to stretch that concept, and I agree that src/mem/testers is an
equally reasonable place for things like this to live. However, I think
the most important thing is that all the similar modules should be in the
same place, and I'm not convinced that src/mem/testers is enough better
to warrant moving things around. If anyone feels strongly about this, feel
free to speak up.
Steve
On Sat, Aug 25, 2012 at 10:45 PM, Andreas Hansson
Post by Andreas Hansson
Hi Nilay,
I see your point. However, there is currently nothing in gem5 to simulate
the "non-CPU" components in a System on Chip, and that is why we are
adding this traffic generator.
The framework based on the state graphs also enables us to e.g. add a
probabilistic behaviour in terms of graph traversal, and all the "vanilla"
network patterns (that have nothing at all to do with real lifeŠuniform
random, bit reversal, tornado etc) can also be generated if anyone
strongly feels like they add any value.
1) Get the new traffic generator in there. Perhaps src/mem is not the
right location, but it is definitely not a CPU or a tester, so suggestions
are welcome.
2) Progressively rebase some of the existing testers on the more generic
traffic generator.
It is also worth noting that the existing testers are cycle callable (they
tick even when there is nothing to do) and the new traffic generator is
purely event-based.
Andreas
Post by Nilay Vaish
Post by Andreas Hansson
Hi Nilay,
I think the point that Andreas is trying to make is that traffic
generators are useful for more than testing and people want to to use
traffic generators to inject traffic into the systems (many systems have
lots of other traffic going through them, not just CPU traffic). The
traffic generator we posted lets the user specifies a configuration file
that describes what kind of traffic that generator will generate. You
can create infinite different configurations including one that emulates
an hdlcd controller, video encoders or decoders, etc. Anyone who is
interested in a client system should be interested in traffic from other
components in the system and this traffic generator is a good way to
produce some traffic for that purpose. It's far more configurable
than
Post by Nilay Vaish
Post by Andreas Hansson
the testers that currently are in gem5.
The meta-question I have is, why do you care that much? It's a
reasonably small piece of code that is well documented and comes
with a
Post by Nilay Vaish
Post by Andreas Hansson
set of regression tests. It seems like exactly the thing we want in
the
Post by Nilay Vaish
Post by Andreas Hansson
repository.
Since we already have some traffic generators in place, we should be
upgrading those if possible. I would prefer if we have only a single
way
Post by Nilay Vaish
to generate a given type of traffic.
--
Nilay
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
nathan binkert
2012-08-24 20:54:33 UTC
Permalink
Post by Andreas Hansson
How does the network tester relate to the traffic gen? I do not see how
there is any possibility to use it for the use-cases that are captured by
the traffic gen. Could you explain what you were referring to?
Question: Is the right thing to have a bunch of separate things like
we have now, or something more unified. I'm mostly concerned about
overlap/duplication, but simplicity is definitely an advantage. Also,
if you're interested, I have a bunch of different testers for random
distributions, traces, and patterns. Basically they're the stuff
that's in Dally's Interconnections Book (I highly recommend reading
the section on simulation, because there's a decent chance you're
accounting for latency incorrectly because it's a bit counterintuitive
how to do it right).

Nate
Andreas Hansson
2012-08-24 21:19:03 UTC
Permalink
Hi Nate,

I think the current traffic gen is a good trade-off. It is a simple
framework of state graphs, where each state if very simple. Each and every
single tester we have could probably be a state if desired. Hence, make
complex things out of simple blocks, and re-use all the rest.

Dally's book is very much focused on off-chip networks and there are bits
and pieces that are quite far from the on-chip world (uniform random
patters etc, bisection bandwidth etc), but I agree that there are a lot of
useful pieces in it too. I'll have another look at the section you mention
:)

Andreas
Post by nathan binkert
Post by Andreas Hansson
How does the network tester relate to the traffic gen? I do not see how
there is any possibility to use it for the use-cases that are captured by
the traffic gen. Could you explain what you were referring to?
Question: Is the right thing to have a bunch of separate things like
we have now, or something more unified. I'm mostly concerned about
overlap/duplication, but simplicity is definitely an advantage. Also,
if you're interested, I have a bunch of different testers for random
distributions, traces, and patterns. Basically they're the stuff
that's in Dally's Interconnections Book (I highly recommend reading
the section on simulation, because there's a decent chance you're
accounting for latency incorrectly because it's a bit counterintuitive
how to do it right).
Nate
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Andreas Hansson
2012-09-10 17:12:25 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1368/
-----------------------------------------------------------

(Updated Sept. 10, 2012, 10:12 a.m.)


Review request for Default.


Description (updated)
-------

Changeset 9215:d51d19a981c4
---------------------------
TrafficGen: Add a basic traffic generator

This patch adds a traffic generator to the code base. The generator is
aimed to be used as a black box model to create appropriate use-cases
and benchmarks for the memory system, and in particular the
interconnect and the memory controller.

The traffic generator is a master module, where the actual behaviour
is captured in a state-transition graph where each state generates
some sort of traffic. By constructing a graph it is possible to create
very elaborate scenarios from basic generators. Currencly the set of
generators include idling, linear address sweeps, random address
sequences and playback of traces (recording will be done by the
Communication Monitor in a follow-up patch). At the moment the graph
and the states are described in an ad-hoc line-based format, and in
the future this should be aligned with our used of e.g. the Google
protobufs. Similarly for the traces, the format is currently a
simplistic ad-hoc line-based format that merely serves as a starting
point.

In addition to being used as a black-box model for system components,
the traffic generator is also useful for creating test cases and
regressions for the interconnect and memory system. In future patches
we will use the traffic generator to create DRAM test cases for the
controller model.

The patch following this one adds a basic regressions which also
contains an example configuration script and trace file for playback.


Diffs (updated)
-----

src/cpu/testers/traffic_gen/SConscript PRE-CREATION
src/cpu/testers/traffic_gen/TrafficGen.py PRE-CREATION
src/cpu/testers/traffic_gen/traffic_gen.hh PRE-CREATION
src/cpu/testers/traffic_gen/traffic_gen.cc PRE-CREATION

Diff: http://reviews.gem5.org/r/1368/diff/


Testing
-------

util/regress all passing (disregarding t1000 and eio)


Thanks,

Andreas Hansson
Ali Saidi
2012-09-10 17:31:43 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1368/#review3424
-----------------------------------------------------------

Ship it!


Ship It!

- Ali Saidi
Post by Andreas Hansson
-----------------------------------------------------------
http://reviews.gem5.org/r/1368/
-----------------------------------------------------------
(Updated Sept. 10, 2012, 10:12 a.m.)
Review request for Default.
Description
-------
Changeset 9215:d51d19a981c4
---------------------------
TrafficGen: Add a basic traffic generator
This patch adds a traffic generator to the code base. The generator is
aimed to be used as a black box model to create appropriate use-cases
and benchmarks for the memory system, and in particular the
interconnect and the memory controller.
The traffic generator is a master module, where the actual behaviour
is captured in a state-transition graph where each state generates
some sort of traffic. By constructing a graph it is possible to create
very elaborate scenarios from basic generators. Currencly the set of
generators include idling, linear address sweeps, random address
sequences and playback of traces (recording will be done by the
Communication Monitor in a follow-up patch). At the moment the graph
and the states are described in an ad-hoc line-based format, and in
the future this should be aligned with our used of e.g. the Google
protobufs. Similarly for the traces, the format is currently a
simplistic ad-hoc line-based format that merely serves as a starting
point.
In addition to being used as a black-box model for system components,
the traffic generator is also useful for creating test cases and
regressions for the interconnect and memory system. In future patches
we will use the traffic generator to create DRAM test cases for the
controller model.
The patch following this one adds a basic regressions which also
contains an example configuration script and trace file for playback.
Diffs
-----
src/cpu/testers/traffic_gen/SConscript PRE-CREATION
src/cpu/testers/traffic_gen/TrafficGen.py PRE-CREATION
src/cpu/testers/traffic_gen/traffic_gen.hh PRE-CREATION
src/cpu/testers/traffic_gen/traffic_gen.cc PRE-CREATION
Diff: http://reviews.gem5.org/r/1368/diff/
Testing
-------
util/regress all passing (disregarding t1000 and eio)
Thanks,
Andreas Hansson
Loading...