Archived

This forum has been archived. Please start a new discussion on GitHub.

AMD/AMI throughput

hi

i've converted the Ice/demo/throughput to make use of AMD/AMI.

AMI for small number of request, +- 100, to an AMD server works. Running a 10k or 100k repititions does not. Seems the client just hangs. It receives some responses but not all.

Do you have any idea what might be wrong? Have you tried running the throughput demo using AMD/AMI?

I can post my modifications if it will help.

Comments

  • marc
    marc Florida
    Yes, please post the modifications. I can't say what the reason might be without seeing the code.
  • Here is the changes. Only changes were to Client.cpp, Throughput.ice and ThroughputI.h

    Hope this helps.
  • marc
    marc Florida
    This code is not correct:

    while( repetitions < numResults )
    usleep(100);

    There is no mutex protection for numResults. You must lock g_mutex before you check numResults.

    Also, I would suggest to use a proper wait/notify. The busy-wait above is very inefficient (even with the short sleep). I.e., make g_mutex a monitor, and then do something like this:

    {
    Monitor<Mutex>::Lock lock(g_monitor);

    while(repetitions < numResults)
    g_monitor.wait();
    }

    And add a g_monitor.notify() if numResults == repetitions in the callback. (Dont' add a notify every time numResults changes, that's inefficient, too. Only if it repetitions == numResults.)
  • Thank you for the reply.

    I agree, the busy wait is not ideal, but was just used for test purposes.

    I've made the changes you suggested. Unfortunately it didn't make a difference. For a 1000 repetitions, the client submitted 651 requests, received 45 responses and then just hangs. Any other ideas?

    I also send SIGABRT to the client when it hangs. The traceback showed that its waiting in a select call. Maybe send/recv buffers are full?

    #0 0x420e19ee in select () from /lib/i686/libc.so.6
    #1 0x4016ac30 in __JCR_LIST__ () from /home/roelof/downloads/corba/Ice-1.1.1/lib/libIce.so.11
    #2 0x400d41cc in IceInternal::Connection::sendAsyncRequest(IceInternal::Handle<IceInternal::OutgoingAsync> const&) ()
    from /home/roelof/downloads/corba/Ice-1.1.1/lib/libIce.so.11
    #3 0x400fc237 in IceInternal::OutgoingAsync::__invoke() () from /home/roelof/downloads/corba/Ice-1.1.1/lib/libIce.so.11
    #4 0x08052785 in IceDelegateM::Throughput::echoByteSeq_async(IceUtil::Handle<AMI_Throughput_echoByteSeq> const&, std::vector<char, std::allocator<char> > const&, std::map<std::string, std::string, std::less<std::string>, std::allocator<std::pair<std::string const, std::string> > > const&) ()
    #5 0x08051e52 in IceProxy::Throughput::echoByteSeq_async(IceUtil::Handle<AMI_Throughput_echoByteSeq> const&, std::vector<char, std::allocator<char> > const&, std::map<std::string, std::string, std::less<std::string>, std::allocator<std::pair<std::string const, std::string> > > const&) ()
    #6 0x08057576 in run(int, char**, IceInternal::Handle<Ice::Communicator> const&) ()
    #7 0x08057fd0 in main ()

    I've attached the modified Client.cpp
  • marc
    marc Florida
    Sorry, but the code is still broken:

    //while( repetitions < numResults )
    // usleep(100);
    g_monitor.wait();


    You cannot wait on a monitor that has not been locked. Also, you must always check the condition before waiting. Please see the chapter about threading in the Ice manual.

    Can you please try with the code from my other post?
  • Your're right, i missed the condition testing part.

    Unfortunately it didn't make a difference...still the same behaviour.

    Modified Client.cpp attached.
  • marc
    marc Florida
    I just tried the latest version of your modifications, and everything works fine on my system.

    What platform is this, what compiler (and version), and which Ice version?
  • Redhat Linux 7.3, Ice 1.1.1, gcc version 3.1 20020604 (Red Hat Linux 7.3 3.1-5). Is there a newer version of ice available?
  • marc
    marc Florida
    No, 1.1.1 is the newest (released) version.

    As I said, I can't reproduce this. Did you compile GCC with threading support? Also, I think version 3.1 was quite buggy. Can you perhaps try the latest version? (Make sure to configure with threading, option --enable-threads for configure.)
  • Thank you. I'll give gcc latest a try (although that'll take a bit more time).

    regards.