[j-nsp] MX104 capabilities question

[joel jaeggli]

On 6/21/16 7:12 PM, Josh Hoppes wrote:
> PAE can get the kernel to address more than 4GB of RAM, however a single
> process will still be limited.

this is straying off topic but.

yeah it doesn't use pae...

Arista kernels are 64 bit, user space is 32 bit derived from FC14.

Linux XXXXXXXXXX 3.4.43.Ar-3052562.4155M #1 SMP PREEMPT Sun Mar 20
19:36:57 PDT 2016 x86_64 x86_64 x86_64 GNU/Linux

all the control-plane cpus are 64 bit with the TORs having AMD apus. and
the beefier boxes having and intel xeon based RE.

big

processor	: 7
vendor_id	: GenuineIntel
cpu family	: 6
model		: 42
model name	: Intel(R) Xeon(R) CPU  @ 2.60GHz
stepping	: 7

little (this is a 7048t which is old)

processor	: 1
vendor_id	: AuthenticAMD
cpu family	: 16
model		: 6
model name	: AMD Turion(tm) II Neo N41H Dual-Core Processor
stepping	: 3
microcode	: 0x10000b6
cpu MHz		: 1499.919

that said 4GB (which is typical for the single asic tors up until very
recently) is kinda tight, depending on how you use them so the older
boxes aren't going to last forever.


> On Tue, Jun 21, 2016 at 8:02 PM, Colton Conor <colton.conor at gmail.com>
> wrote:
> 
>> Saku,
>>
>> Can you expand on what you mean by the following quote: "I think they are
>> fundamentally able to produce less buggy code than
>> JNPR or CSCO.

yeah if there's any fundamental about it, it's that it carry less
legacy, is more general purpose, and has less hardware, wierd corner
cases and unreasonable customer demands to support. It has it share of
bugs, missing features and hardware specific limitations and quirks.

>> They are doing some of the classic mistakes, like
>> insisting market that they have single image like JNPR highlighted as
>> big competitive advantage over CSCO back in the day. But they'll need
>> to get rid of this message when moving to 64b or then they need to
>> screw people running older HW not capable for 32b."
>>
>> My understanding is right now they indeed do have a single downloadable
>> file no matter which arista switch model you have. Is that not the case?
>> Are you saying this file is 32 bit and not 64? That would suprise me since
>> I beleive most of their recent switches have more than 8GB of RAM in them.
>>
>> On Thu, Jun 9, 2016 at 8:39 AM, Saku Ytti <saku at ytti.fi> wrote:
>>
>>> On 9 June 2016 at 15:54, Mark Tinka <mark.tinka at seacom.mu> wrote:
>>>
>>>> But is the IP and MPLS code mature enough for real-world use?
>>>
>>> It's getting there, customer by customer. It's not there for me. I
>>> expect Arista to be serious player in SP segment in a <2 years.
>>>
>>> As Arista is still controlled by owners who work there on daily basis,
>>> they can do things well, instead of seeking immediate gratification
>>> while adding technological debt. And none of them are in their first
>>> rodeo, are financially independent so I don't think they're interested
>>> in doing big exit, I think they're solely motivated in building great
>>> company and a great product. How long this issue will persist is
>>> anyone's guess.
>>>
>>> They do something quite different than JNPR or CSCO. I think
>>> programming language is important, and I think C is terrible language,
>>> because it's very hard to write quality code on.
>>> Arista isn't really using C, mostly C++ and good portion of that is
>>> machine generated from their own proprietary state description
>>> language. They also heavily unit test and automate black-box testing.
>>>
>>> I think they are fundamentally able to produce less buggy code than
>>> JNPR or CSCO. They are doing some of the classic mistakes, like
>>> insisting market that they have single image like JNPR highlighted as
>>> big competitive advantage over CSCO back in the day. But they'll need
>>> to get rid of this message when moving to 64b or then they need to
>>> screw people running older HW not capable for 32b.
>>>
>>> I wish someone would do something even more novel, like create full
>>> routing suite in Erlang. But from what we have now in the market, I
>>> think Arista is most innovative.
>>>
>>> --
>>>   ++ytti
>>>
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20160622/7b62fb50/attachment.sig>