Joseph Ashwood wrote:

As has been pointed out it's not latency but latency/messages that matters. If there are 2 messages a day going through the system then 5 minutes is simply not enough, it will be completely traceable. OTOH if there are 5000/sec going through the system then 5 minutes is arguably overkill.

Oh, I think I understand the confusion now. There is a latency feature which allows a sender to request a message be held for some specified length of time before being placed in the message pool. In essence, the arrival of the message to the core of the remailer is delayed. This is a fine feature - it is almost a requirement for a really good remailer net. However, the latency I am discussing is less complicated - it's just the average time a message remains in the remailer when it's being sent straight through the system with no extra latency requested. In other words, a message which is sent in such a way that transit time is minimized. It is not something the sender can, or would want to, specify. This value is a function only of the pool sizes of the remailers and the number of messages sent through over a period of time. For example, let's say we have 10 remailers and 100 users. How many messages a day do these users have to send to see an average latency of 5 min. per hop? (Assume the pool size is 30.) Each remailer must handle 30 msgs / 5 min. = 6 msgs/min, or 8,640 msgs/day. Assuming each user routes their messages through 20 hops, each message will go through each remailer twice, on average. So, the users will send 8,640 msgs/2 = 4,320 msgs during the day. On average, each user would send 43.2 messages per day, or one every 33.33 minutes. So, you can see that this is quite feasible if people are sending any news feeds, mailing lists, cover traffic, or even just a lot of e-mail through the system.