On Wed, 11 Apr 2001, Joseph Mack wrote:
> With a planned time of summer for the switch off, I'm looking for
> info that will help me design some hardware for it. I don't see
> anything on the website, but if I'm to enter a box for a
> switch-off this summer, I need to know some details soon. If a
> notice appears on the website saying "run these tests and submit
> the output in 3 weeks if you want to enter" I won't be able to do
> it. Thanks
Preliminary workloads for the switch-off will be available much
earlier than 3 weeks before the event, probably this month as
Polygraph version 2.6.0 is finally released. You will be able to use
those workloads to test your product(s). In addition to that, you can
submit your product for private tests (we have been running those for
quite a while now, while polishing the workloads).
> I'm mostly interested in the bandwidth I'll be required/able to
> process.
There will be no minimum bandwidth requirements. Virtually any
positive load is acceptable. "Ability" will depend on the workload, of
course.
> I assume that you will be providing client(s) and server(s) and I
> will be providing my L-4 setup as a black box to plug into your
> setup.
This is correct. We will ask you to configure your box based on the
switch-off rules (IP addresses and such), but any reasonable L4 switch
should be able to satisfy those.
> What type of connections do I get to your setup? One cable to the
> client farm/ to the server farm, or one cable to each of the nodes
> (ie many cables)? Is the connection 100MBps, 1GBps?
Good questions. We can do either or both. I think this configuration
issue should be discussed by potential participants before a final
decision can be made.
Polygraph clients and servers will most likely have one 100Mbps NIC
each.
> How many client(s), server(s) boxes will be involved? Is it a set
> number or do you keep adding boxes till the L-4 box saturates?
The number of Polygraph PCs will depend on the peak load level you
want to demonstrate at the switch-off. That is, you tell us the peak
request rate (or bandwidth), we provide enough clients and servers and
run the test to verify your claims.
Keep in mind that request rate is not the only metric involved. In our
private tests we have seen many situations where response time and
other measurements would change significantly with load, way before
the switch is saturated. Thus, you may have to solve a trade-off:
getting higher load versus getting better response time/etc.
> What is the bandwidth of the client and server boxes? Can they
> saturate their network interface(s) (whatever the interface(s) may
> be).
Depending on the workload, we can saturate a 100Mbit link (~90%
utilization). However, it is usually not safe or realistic to run at
those levels. For cache-offs, we run at about 50% link utilization
levels, but that may change for the switch-offs. This decision will
also depend on how/if the client/server-side traffic is aggregated.
> What is the latency/throughput between one of your client boxes
> and one of your server boxes when connected by a crossover cable
> and running a netpipe test?
The added latency depends on the load. We will publish some no-switch
results soon.
> What range of IP's will the clients be using? The servers? (I assume
> the servers will be presenting IPs from the whole or most of IP space).
> I assume that the IP space for the clients and servers are separate?
There will be thousands of client IPs and few server IPs, depending on
the load. For example, each Polygraph robot can be configured with a
single unique IP address and can be told to emit 0.5 requests per
second. To get 500 req/sec, one would use 1000 robots (1000 IP
addresses), and so on. One client PC can host thousands of robots.
There will be one or a few simulated servers per server-side PC. The
exact formula will be decided by the participants.
All IP addresses are likely to come from the "reserved" address spaces
(10.x and such) unless there are very good reasons to make them truly
random. Note that non-flat network configurations will require routing
devices in the test setup. Hopefully, we can accommodate most IP
hashing algorithms without making the setup too complex.
> Are cache boxes in front of the servers? Do you provide them,
> Should I provide them?
We are likely to test switches in a origin server load balancing mode
so no caches will be necessary. If most participants want to test
proxy load balancing instead, we will try to provide caches (based on
polypxy cache).
> Does the web content provided by the servers have "locality",
> ie will a particular URL or piece of content be only presented
> from one box.
Polygraph can support both environments. Participants will probably
have to agree on one.
> If the details aren't settled yet, can you give me enough
> approximate information that I can plan something.
I hope the above helps. Until 2.6 is released, you may want to look at
the WebAxe workload as a prototype example. If you have any particular
suggestions or preferences, please let us know!
> Do you have any idea when in "summer" the switch-off might be.
If I have to guess, I would say July. We are working on a CFP for the
switch-off. It is our rule to let potential participants to discuss
timing and other details before the rules are settled.
HTH,
Alex.
This archive was generated by hypermail 2b29 : Tue Jul 10 2001 - 12:00:18 MDT