Dahdi for meetme on AMD64 arch?

Home » Asterisk Users » Dahdi for meetme on AMD64 arch?
Asterisk Users 3 Comments

2012-01-19 13:27, Doug Lytle skrev:
>
> Tony Mountifield wrote:
>> It may be a stupid question just displaying ignorance on my part, but
>> why are you using*AMD*64 architecture on an *Intel* processor?
>> Surely for 64-bit, you should be using x86_64 architecture instead?
>
>
> From what I’ve read, AMD came out with the extended instruction set
> and Intel just implemented it as is.
>
> It’s basically the same for both processors.
>
> Doug
>
I found this wiki http://wiki.debian.org/DebianAMD64Faq ,
it states that AMD64 / Intel64 / x86_64 are the same thing:

Debian on AMD64 FAQ

Q: Is this port only for AMD 64-bit CPUs?
A: No. “AMD64” is the name chosen by AMD for their 64-bit extension to
the Intel x86 instruction set. Before release, it was called “x86-64” or
“x86_64”, and some distributions still use these names. Intel refers to
its AMD64 implementation as “Intel64” previously named “EM64T”. The
architecture is AMD64-compatible and Debian AMD64 will run on AMD and
Intel processors with 64-bit support. Because of the technology
paternity, Debian uses the name “AMD64”.

I’ve always wondered about the “amd” in the name, but it makes sense
now. Thanks for the input..

3 thoughts on - Dahdi for meetme on AMD64 arch?

  • 2012-01-18 20:06, Shaun Ruffell skrev:
    Yes! That did it. Thank you!

    This time it wasn’t as much channels active as the last time. It was 32
    channels active, and the last time 57.
    In the beginning of the next week there will be more users to reproduce
    the test with more channels, and I will begin to work with a test
    configuration to create some channels from another server. (Should have
    done that a long time ago I guess)

    I will hold up migration of more customers to this server, so we can
    test your patch against Dahdi 2.6.

    This is the the server with dahdi_dummy idle:
    99.999% 99.997% 100.000% 99.999% 99.999% 99.994% 99.997% 99.999%
    99.997% 99.999% 99.999% 99.999% 99.999% 99.999% 99.998% 99.999%
    99.999% 99.998% 99.998% 99.999% 99.999% 99.999% 99.998% 99.999%
    99.999% 99.998% 99.998% 100.000% 99.999% 99.998% 99.999% 99.999%
    99.998% 99.998% 99.999% 99.998% 99.998% 99.999% 99.998% ^C

  • 2012-01-18 19:44, John Knight skrev:

    Good to know that it is working! I’ve run i386 earlier, but thought it
    was time to try 64-bit.

    I’ve been quite happy with Debian. Previously I was using BSD, and it
    was almost impossible to upgrade the system. And apt / dpkg have never
    failed me, very impressive. I guess rhel works well also, but I’ve
    little experience with it.

    Why doesn’t Debian use the rhel6-openvz-kernel if that is the one that
    is maintained?
    Are you sure they use an outdated kernel?

    I have to read up on this, the next server maybe should use another
    distro for the HN.
    Maybe I will try switch to lxc instead of openvz as it is in the
    mainline kernel now. After all I need two things: Isolation, and the
    possibility to run multiple asterisk VEs on the same physical machine.

  • Debian is a great distribution as well. I still use it as the container
    os to host web vps. I think for OpenVZ usage though, it would be best
    to at least run your node software on the same distribution that is
    targeted via OpenVZ dev staff. You shouldn’t really be doing anything
    else on your node anyway, so the os type shouldn’t really interfere I
    would think. Though this argument breaks down when I suggest it to my
    Debian-using friends who seem to have a knee-jerk right hook coming my
    way when I mention rhel/centos. 😀

    I didn’t see an “el6” tag on your kernel version that you first posted
    which means it’s probably based on the 2.6.32 vanilla branch
    (http://wiki.openvz.org/Download/kernel/2.6.32). The el6 version
    (http://wiki.openvz.org/Download/kernel/rhel6) is the only known
    actively developed branch of 2.6.32 that I know of. I can’t imagine
    Debian not packaging it up correctly by not reflecting the correct
    branch information. Though it’s only been a year and half since
    2.6.32-el6 has been around, I’ve already seen quite a bit of bug fixes,
    security fixes and backports added to it so it’s already diverging quite
    heavily from the vanilla branch. Something that works flawlessly on
    2.6.32-el6 might not work the same way on 2.6.32, and I’m wondering if
    this might be a cause of issues.

    To Digium: Does Digium test dahdi against a specific set of kernels such
    as 2.6.18-el5 and 2.6.32-el6 or do they only test against the vanilla
    upstream branches or a mixture? Dahdi target platforms would be
    interesting to know in relation to the context of Johan’s dahdi problem.

    Hmm, I’ve never used lxc. It definitely sounds interesting. If you’re
    going to implement it running Asterisk, I’d love to know if there are
    any issues or special methods required to get dahdi running (such as the
    DEVNODES feature in vz).

    Also, sorry to anyone if I’ve veered too far offtopic, I’m quite
    interested and invested in openvz/asterisk/dahdi interoperability.