By: Etienne (etienne_lorrain.delete@this.yahoo.fr), August 13, 2014 3:09 am
Room: Moderated Discussions
Gabriele Svelto (gabriele.svelto.delete@this.gmail.com) on August 12, 2014 11:31 pm wrote:
> Etienne (etienne_lorrain.delete@this.yahoo.fr) on August 11, 2014 7:17 am wrote:
> > IHMO, ISA does not matter because we are talking of a server and not an HPC machine.
> > What (I think) people really want is a server which can boot to full service in under a second,
> > so that rebooting a server has the same consequences as loosing few TCP packets.
>
> Why? If continuous connectivity is important then there's redundancy setups
> which would allow you to reboot a server without losing any packets at all.
I think such an ARM based server will not fit every server market, because that is not the fastest ever processor produced.
If the target market is small organisations, from the home server to show family videos/photos, to shops/associations to manage membership, forums, maybe a SVN/GIT server - then the buyer will not want to make/manage a redundant setup.
For that use case, an ARM system may be well suited, because the (very big video) file to send do not need to enter the processor memory cache - some well designed "coprocessor" can receive the file directly from the hard disk (few milliseconds later) and format the stuff ready to put on Ethernet "coprocessor" - and tell the processor when the whole stuff is finished.
In other words the Linux "sendfile" service do not need to put the content of the file in the page-cache.
Note that in the list of coprocessor at fixed address I was talking of, I forgot one set of "encryption" modules to provide HTTPS:// - with an interface good enough not to need complex processor calculus.
> Etienne (etienne_lorrain.delete@this.yahoo.fr) on August 11, 2014 7:17 am wrote:
> > IHMO, ISA does not matter because we are talking of a server and not an HPC machine.
> > What (I think) people really want is a server which can boot to full service in under a second,
> > so that rebooting a server has the same consequences as loosing few TCP packets.
>
> Why? If continuous connectivity is important then there's redundancy setups
> which would allow you to reboot a server without losing any packets at all.
I think such an ARM based server will not fit every server market, because that is not the fastest ever processor produced.
If the target market is small organisations, from the home server to show family videos/photos, to shops/associations to manage membership, forums, maybe a SVN/GIT server - then the buyer will not want to make/manage a redundant setup.
For that use case, an ARM system may be well suited, because the (very big video) file to send do not need to enter the processor memory cache - some well designed "coprocessor" can receive the file directly from the hard disk (few milliseconds later) and format the stuff ready to put on Ethernet "coprocessor" - and tell the processor when the whole stuff is finished.
In other words the Linux "sendfile" service do not need to put the content of the file in the page-cache.
Note that in the list of coprocessor at fixed address I was talking of, I forgot one set of "encryption" modules to provide HTTPS:// - with an interface good enough not to need complex processor calculus.