This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/
[address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)")
- Previous message (by thread): [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)")
- Next message (by thread): [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 PolicyClarification - Initial allocation criteria "d)")
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Masataka Ohta
mohta at necom830.hpcl.titech.ac.jp
Tue Jun 22 14:26:30 CEST 2004
Oliver Bartels: >>So that would be a maximum of 10.000 routing table entries (if we >>can manage to keep it at "1 prefix per LIR"). > > Full Ack. > > A table of this size is handled with a one cycle memory access > in modern routing hardware. By definition of "one cycle memory access", any table of any size can be handled with a one cycle memory access in any routing hardware. However, memory access cycle can be a lot larger than a CPU clock cycle. On typical modern chips, tens of registers can be accessed within a CPU cycle. On chip primary cache with thousands of entries needs about twice or three times more than that. Off chip cache needs about ten, twenty or, maybe, hundred more to access. Masataka Ohta
- Previous message (by thread): [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)")
- Next message (by thread): [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 PolicyClarification - Initial allocation criteria "d)")
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]