[GTER] Accel PPP
Henrique Marks
henrique.marks at datacom.ind.br
Thu Nov 22 17:42:29 -02 2018
----- Mensagem original -----
> De: "André Carlim" <andre at stubnet.info>
> Para: "Grupo de Trabalho de Engenharia e Operacao de Redes" <gter at eng.registro.br>
> Enviadas: Quinta-feira, 22 de novembro de 2018 10:14:33
> Assunto: Re: [GTER] Accel PPP
> Em 2018-11-21 18:23, marcoslistas at turbonetbr.com.br escreveu:
>> Pessoal Alguem já conseguiu instalar Accel PPP em Edge Router
>> estou bastante propenso a abandonar o pppoe e partir para IPoE uma das
>> coisas que ainda esta me segurando são os pequenos pop's onde não é
>> possível a instalação de servidores (questões de espaço e energia) para
>> instalação do Accel para estes locais pensei na ipotese de uma Edge
>> Router caso seja possível a instalação do Accel, infelizmente o
>> RouterOS
>> ainda não tem suporte pois nestes casos uso uma RB como concentrador.
>>
>> algum case de sucesso ?
>
> Então, não é querer desanimar, mas como o accel-ppp foi desde o inicio
> desenvolvido para arquitetura x86 tem uso frequente de funções que só
> processadores dessa arquitetura "entendem" aí na compilação cruzada faz
> uma abstração da função para compensar, e isso é péssimo, o meio
> confiável seria reescrever o código para arm e mips para poder usar
> nessas arquiteturas.
>
> O que eu quero dizer é que já tentei muito isso e até mesmo em contato
> com o mantenedor do projeto, ele me disse que não tem tempo para fazer
> isso, então se tem alguém aí que manje de C para mips e arm, podemos
> montar um grupo para "portar" ele, de outro modo não vai funcionar.
Honestamente isto não faz sentido. A linguagem C, e a biblioteca padrão de C, existem exatamente para impedir este problema. Você escreve um código CERTO, em C, e compila ele para diferentes arquiteturas, tendo, é claro, um toolchain adequado para cada uma destas arquiteturas (compilador, binutils, libc (pode ser a glibc, por exemplo).
O problema é escrever o código correto em C. Por exemplo, ainda não olhei o código do accel-ppp (mas vou olhar, reporto depois!), mas pode ter erros básicos de endianess, pelo mau-uso de funções padrão de conversão de endianess (htonl, ntohl, etc.). Neste caso, o código pode ter sido escrito para o endianess usado nos x86 (que é diferente de ARM, PowerPC, MIPS, via de regra).
Outro problema comum é usar bibliotecas não-padrão, que não tem "porte" para a arquitetura-alvo, ainda. Mas isto é mais incomum hoje.
Um problema com alguns sistemas "meio-abertos" é que não são disponibilizados os toolchains para a arquitetura-alvo, então você não tem um compilador e conjunto de ferramentas para fazer o porte. Isto pode realmente dificultar tudo.
Mando depois outra resposta assim que analisar o código, para ver se os potenciais problemas seriam estes.
Até mais
>
> Sobre não poder usar servidor por questões de espaço e energia, pense
> bem, hoje tem o server-u que tanto o L-400 quanto o L-800, apesar de
> caríssimos, tem opção de comprar já com a fonte de -48v e o servidor é
> do tamanho desses switchs tp-link melhores, ou seja, espaço e energia
> não afetam mais o uso. Além disso tem uns servidores IBM (eu ainda não
> vi pessoalmente), mas dois clientes já pegaram e eu configurei o accel,
> que eles falaram que pegaram com fonte de 12v a 24v, achei espetacular,
> o servidor tem um processador octa-core desses Xeon E5, com frequência
> alta, 4 portas metalicas de 1G com chip intel i350-T4, e mais duas
> portas de 10G com chip intel 82599, achei espetacular, como disse não
> sei ao certo as dimensões, até acho que é alguém que vende o servidor
> normal, e apenas troca a fonte, é meu palpite, pois não achei nenhum
> datasheet da própria IBM sobre isso.
>
>
> Em 2018-11-21 21:26, Uesley Correa escreveu:
>> Opa!
>>
>> Accel em edge router com ipoe depende do SDK da cavium pra compilar. Se
>> você tiver o SDK e uma VM Debian consegue fazer um Cross e gerar um
>> .deb
>> mas se não tiver o SDK nada feito. Ainda há a possibilidade de dar
>> problema
>> entre Big endian e little endian (acho que a CPU da Edge não suporta o
>> big
>> se não me falta a memória). Pra esses cases eu usaria mini PC ao invés
>> de
>> Edge pra manter a arquitetura em x86 ao invés de mips.
>
> Uesley, eu já tentei muito isso com as edgerouters, infelizmente
> funciona bem por algumas horas e já começam os problemas com
> inconsistências na memória, mesmo com o SDK e compilado especificamente
> nele, dá problema, é o que expliquei em cima ali.
>
>
>
> ---
>
> Atenciosamente,
> André Carlim
> StubNetwork
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
--
Dr. Henrique Marks
henrique.marks at datacom.ind.br
R. América, 1000 - Eldorado do Sul - RS
CEP: 92990-000 - Brasil
Fone: +55 51 3933 3000 - Ramal 3466
More information about the gter
mailing list