Some measurements and some questions

[Eddie Kohler]

Hi Brecht, sorry for so long getting back to you.

> * it seems that the routing table is a very consuming component, see the
> document between click 3 (entries for 2 subnets) and click 4 (entries for
> 5 subnets) which makes the latency a lot higher than the standard linux.
> Is this a known issue ?

This is a known issue. Unfortunately, much of the published routing table
work has been patented, and we cannot include it. We are not real routing
table hackers so we just left it at that. Do you know of any good
unpatented routing tables? Or, of course, you could write a better one and
contribute it to the Click distribution :)

> * If there is given a parameter which is bigger than 2100000 bytes per
> second (16Mbit/s), the /proc/click/meter/meters gives a minus rate and the
> component doesn't do what is expected.

We will fix this to give a warning.

> * Is there an upcoming meter component which has the behaviour as needed
> in diffserv, this is all traffic under the limit goes through and only the
> out of rate packets are dropped or remarked. Now the meter component sends
> all traffic to one output according to the rate. (e.g. a 2 Mbit stream
> through a 1 Mbit meter goes all trhough output 1, but normally only
> half of the traffic should be going through output 1)

There will be one soon. The problem is preventing burstiness; not clear
what the best way is. Maybe not in Click 1.1. Do you have any ideas here?

> * When will click-1.1 be published as described in the TOCS paper ?

Probably at the end of this week.

> * The use of the optimisation (fastclassifier, devirtualise) doesn't seem
> spectacular, is this normal ?

It depends on your configuration. If there are no clsasifiers,
fastclassifier won't do anything, for example.

> * When the time parameter to UDP gen is givenfor e.g. 10 seconds, it sends
> only traffic for 5 seconds ?

My udpgen.o does not have this behavior....

> * In the help of UDP gen is stated that the data in the UDP packet is :
> UDP data, but the actual data is 'UDP packet !' (minor bug :-) )

Thanks for catching this :)

> * Are the syslog messages like : 'tulip_start_xmit while interrupts off
> and eth2: Tx hung, 966228 vs. 966227' alarming ?

I'll forward this question to someone else.

> * Is there a plan to implement the mixed interrupt driven/polling method
> as in the paper 'Eliminating Receive Livelock' (because now the PC is
> continuously for 100% loaded, which produces a lot of heat day and night)

Not right now, but that is probably the best reason we've heard to actually
bother to do it. Are you interested in helping?

> * Is it possible to print the tulip stats as in the function
> tulip_print_stats ?

Could you explain what you mean? When do you want to print this?

love,
ed