<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body>
Would that chip be suitable, i.e. can we expect most names to fit in
(the magnitude of) 96 bytes? What length are names usually in
current NDN experiments?<br>
<br>
I guess wide deployment could make for even longer names. Related:
Many URLs I encounter nowadays easily don't fit within two 80-column
text lines, and NDN will have to carry more information than URLs,
as far as I see.<br>
<br>
<div class="moz-cite-prefix">On 18/Sep/14 23:15, <a class="moz-txt-link-abbreviated" href="mailto:Marc.Mosko@parc.com">Marc.Mosko@parc.com</a>
wrote:<br>
</div>
<blockquote cite="mid:096077D8-5479-4CC2-A0F0-1990CDDE57F4@parc.com"
type="cite">
<pre wrap="">In fact, the index in separate TLV will be slower on some architectures, like the ezChip NP4. The NP4 can hold the fist 96 frame bytes in memory, then any subsequent memory is accessed only as two adjacent 32-byte blocks (there can be at most 5 blocks available at any one time). If you need to switch between arrays, it would be very expensive. If you have to read past the name to get to the 2nd array, then read it, then backup to get to the name, it will be pretty expensive too.
Marc
On Sep 18, 2014, at 2:02 PM, <a class="moz-txt-link-rfc2396E" href="mailto:Ignacio.Solis@parc.com"><Ignacio.Solis@parc.com></a> <a class="moz-txt-link-rfc2396E" href="mailto:Ignacio.Solis@parc.com"><Ignacio.Solis@parc.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Does this make that much difference?
If you want to parse the first 5 components. One way to do it is:
Read the index, find entry 5, then read in that many bytes from the start
offset of the beginning of the name.
OR
Start reading name, (find size + move ) 5 times.
How much speed are you getting from one to the other? You seem to imply
that the first one is faster. I don¹t think this is the case.
In the first one you¹ll probably have to get the cache line for the index,
then all the required cache lines for the first 5 components. For the
second, you¹ll have to get all the cache lines for the first 5 components.
Given an assumption that a cache miss is way more expensive than
evaluating a number and computing an addition, you might find that the
performance of the index is actually slower than the performance of the
direct access.
Granted, there is a case where you don¹t access the name at all, for
example, if you just get the offsets and then send the offsets as
parameters to another processor/GPU/NPU/etc. In this case you may see a
gain IF there are more cache line misses in reading the name than in
reading the index. So, if the regular part of the name that you¹re
parsing is bigger than the cache line (64 bytes?) and the name is to be
processed by a different processor, then your might see some performance
gain in using the index, but in all other circumstances I bet this is not
the case. I may be wrong, haven¹t actually tested it.
This is all to say, I don¹t think we should be designing the protocol with
only one architecture in mind. (The architecture of sending the name to a
different processor than the index).
If you have numbers that show that the index is faster I would like to see
under what conditions and architectural assumptions.
Nacho
(I may have misinterpreted your description so feel free to correct me if
I¹m wrong.)
--
Nacho (Ignacio) Solis
Protocol Architect
Principal Scientist
Palo Alto Research Center (PARC)
+1(650)812-4458
<a class="moz-txt-link-abbreviated" href="mailto:Ignacio.Solis@parc.com">Ignacio.Solis@parc.com</a>
On 9/18/14, 12:54 AM, "Massimo Gallo" <a class="moz-txt-link-rfc2396E" href="mailto:massimo.gallo@alcatel-lucent.com"><massimo.gallo@alcatel-lucent.com></a>
wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Indeed each components' offset must be encoded using a fixed amount of
bytes:
i.e.,
Type = Offsets
Length = 10 Bytes
Value = Offset1(1byte), Offset2(1byte), ...
You may also imagine to have a "Offset_2byte" type if your name is too
long.
Max
On 18/09/2014 09:27, Tai-Lin Chu wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">if you do not need the entire hierarchal structure (suppose you only
want the first x components) you can directly have it using the
offsets. With the Nested TLV structure you have to iteratively parse
the first x-1 components. With the offset structure you cane directly
access to the firs x components.
</pre>
</blockquote>
<pre wrap="">I don't get it. What you described only works if the "offset" is
encoded in fixed bytes. With varNum, you will still need to parse x-1
offsets to get to the x offset.
On Wed, Sep 17, 2014 at 11:57 PM, Massimo Gallo
<a class="moz-txt-link-rfc2396E" href="mailto:massimo.gallo@alcatel-lucent.com"><massimo.gallo@alcatel-lucent.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 17/09/2014 14:56, Mark Stapp wrote:
</pre>
<blockquote type="cite">
<pre wrap="">ah, thanks - that's helpful. I thought you were saying "I like the
existing NDN UTF8 'convention'." I'm still not sure I understand what
you
_do_ prefer, though. it sounds like you're describing an entirely
different
scheme where the info that describes the name-components is ...
someplace
other than _in_ the name-components. is that correct? when you say
"field
separator", what do you mean (since that's not a "TL" from a TLV)?
</pre>
</blockquote>
<pre wrap="">Correct.
In particular, with our name encoding, a TLV indicates the name
hierarchy
with offsets in the name and other TLV(s) indicates the offset to use
in
order to retrieve special components.
As for the field separator, it is something like "/". Aliasing is
avoided as
you do not rely on field separators to parse the name; you use the
"offset
TLV " to do that.
So now, it may be an aesthetic question but:
if you do not need the entire hierarchal structure (suppose you only
want
the first x components) you can directly have it using the offsets.
With the
Nested TLV structure you have to iteratively parse the first x-1
components.
With the offset structure you cane directly access to the firs x
components.
Max
</pre>
<blockquote type="cite">
<pre wrap="">-- Mark
On 9/17/14 6:02 AM, Massimo Gallo wrote:
</pre>
<blockquote type="cite">
<pre wrap="">The why is simple:
You use a lot of "generic component type" and very few "specific
component type". You are imposing types for every component in order
to
handle few exceptions (segmentation, etc..). You create a rule
(specify
the component's type ) to handle exceptions!
I would prefer not to have typed components. Instead I would prefer
to
have the name as simple sequence bytes with a field separator. Then,
outside the name, if you have some components that could be used at
network layer (e.g. a TLV field), you simply need something that
indicates which is the offset allowing you to retrieve the version,
segment, etc in the name...
Max
On 16/09/2014 20:33, Mark Stapp wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
On 9/16/14 10:29 AM, Massimo Gallo wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
I think we agree on the small number of "component types".
However, if you have a small number of types, you will end up with
names
containing many generic components types and few specific
components
types. Due to the fact that the component type specification is an
exception in the name, I would prefer something that specify
component's
type only when needed (something like UTF8 conventions but that
applications MUST use).
</pre>
</blockquote>
<pre wrap="">so ... I can't quite follow that. the thread has had some
explanation
about why the UTF8 requirement has problems (with aliasing, e.g.)
and
there's been email trying to explain that applications don't have to
use types if they don't need to. your email sounds like "I prefer
the
UTF8 convention", but it doesn't say why you have that preference in
the face of the points about the problems. can you say why it is
that
you express a preference for the "convention" with problems ?
Thanks,
Mark
</pre>
</blockquote>
<pre wrap="">.
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">_______________________________________________
Ndn-interest mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a>
<a class="moz-txt-link-freetext" href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
Ndn-interest mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a>
<a class="moz-txt-link-freetext" href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
Ndn-interest mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a>
<a class="moz-txt-link-freetext" href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Ndn-interest mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a>
<a class="moz-txt-link-freetext" href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a>
</pre>
</blockquote>
<br>
</body>
</html>