pyxida-users Mailing List for Pyxida

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Ok sure I'll terminate the service

2009/5/1 Jonathan Ledlie <jon...@ee...>

>
> I was unclear.  I meant: can you leave the Pyxida service up?  I've added
> the three nodes listed here to my config file.   Then I can connect to it
> and see if I get the same error.
>
> -jonathan
>
>
> On Apr 30, 2009, at 7:51 PM, Cao Cuong Ngo wrote:
>
>  Jonathan,
>>
>> I think the slice is always up ?
>>
>> 2009/4/30 Jonathan Ledlie <jon...@ee...>
>>
>> Cuong: could you leave your slice up so we can connect to it?
>>
>> Peter: do you know what is causing this error?  This looks like something
>> that should be caught by the Async library.
>>
>> -jonathan
>>
>>
>> On Apr 30, 2009, at 4:30 AM, Ngo Cao Cuong wrote:
>>
>> I ran UDP and there're really a lot of nodes with this error:
>>
>> DE 1240936421240 NCManager         : addUpNeighbor: planetlab05.mpi-
>> sws.mpg.de:55924
>> DE 1240936421240 NCManager         : getUpNeighbor using up:
>> planetlab2.ece.ucdavis.edu:55924
>> DE 1240936429765 NCManager         : in GossipHandler cb
>> DE 1240936429765 NCManager         : addUpNeighbor:
>> planetlab1.netmedia.gist.ac.kr:55924
>> DE 1240936429765 NCManager         : getUpNeighbor using up:
>> planetlab1.acis.ufl.edu:55924
>> DE 1240936430133 NCManager         : setting timer to 9616
>> IN 1240936430134 NCManager         : NCManager - stabilized and full
>> IN 1240936430134 NCClient          : getNeighborToPing: pinged/non 32/0
>> avgTimeSincePing 298245.5625 minTime 1
>> IN 1240936430134 NCClient          : getNeighborToPing: lowered
>> MIN_UPDATE_TIME_TO_PING 1
>> IN 1240936430134 NCClient          : getNeighborToPing: picking from
>> grayingNeighbors 32/32 lsirextpc01.epfl.ch:55924
>> DE 1240936430134 NCManager         : getUpNeighbor using up:
>> zju1.6planetlab.edu.cn:55924
>> DE 1240936430134 NCManager         : Sending gossip request to
>> lsirextpc01.epfl.ch:55924
>> WA 1240936430890 ObjComm$ReadConnHa: Received another connection from
>> remoteAddr=lsirextpc01.epfl.ch:55924
>> WA 1240936430890 ObjComm$ReadConnHa: Closing old connection.
>> Exception in thread "main" java.nio.channels.CancelledKeyException
>>  at sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:55)
>>  at sun.nio.ch.SelectionKeyImpl.readyOps(SelectionKeyImpl.java:69)
>>  at edu.harvard.syrah.sbon.async.EL.handleSelectCallbacks(EL.java:770)
>>  at edu.harvard.syrah.sbon.async.EL.main(EL.java:434)
>>  at edu.harvard.syrah.pyxida.Pyxida.main(Pyxida.java:191)
>>
>> Thanks.
>>
>>
>> Jonathan Ledlie wrote:
>>
>> Cuong,
>>
>> A good thing to do would be to run a UDP (not ICMP) test on the same nodes
>> and see what happens.  If you get OK coordinates for this, then we can
>> isolate the problem to be the ICMP code.
>>
>> Also, I had problems with some of the inria nodes as well.
>>
>> Do you know of any event that might have occurred at 100 000 seconds?
>>
>> Also, #2 you should be able to get a reasonable picture in an hour or two
>> (you don't need to wait 170).
>>
>> -jonathan
>>
>> On Apr 24, 2009, at 5:22 AM, Ngo Cao Cuong wrote:
>>
>>
>> Thanks for your response,
>>
>> I wonder for how long we can reach the convergence state ? It should be
>> in maximum 2500 turns ?
>> In fact I plotted the coordinates of all the nodes in 170 hours and it
>> seems not convergent (you could take a look at the coordinates of node
>> onelab03.inria.fr in 170 hours in attached file). For the first
>> 30000-100000 things are good, the coordinates are stable, but after
>> that, about 200000 seconds, it change unstably.
>>
>> Cuong.
>>
>>
>> Jonathan Ledlie wrote:
>>
>> Cuong,
>>
>> Thanks for being our guinea pig :-)
>>
>> It is possible that there are mismatches going on in our Jpcap wrapper.
>> This might explain both problems.
>>
>> So if host A sends two pings to host B and the first one is dropped, we
>> might be returning the latency value as the total of the send of the
>> first to the receipt of the second.
>>
>> Why don't you look at a few inter-node latency distributions and see if
>> what you are getting makes sense?
>>
>> The list [] would happen if one ping was enclosed by another.
>>
>> I started to put some code in that checks the 'ident' received.  The way
>> to fix the problem you see might be to only remove items when the ident
>> matches what has been sent.
>>
>> -jonathan
>>
>> On Apr 23, 2009, at 11:17 AM, Ngo Cao Cuong wrote:
>>
>> Hello,
>>
>> I ran newest Pyxida (from CVS) on Planetlab (about 170 nodes), but
>> after some days there's still nodes quit (about 40), and the
>> coordinates change unstably,
>> I've tracked some errors but don't know how to fix them. Could you
>> take a look and help me fix it.
>>
>> Thank you.
>>
>> An error :
>>
>> DE 1240415906095 NCManager         : !addPendingNeighbor:
>> freedom.ri.uni-tuebingen.de:55904
>> DE 1240415906095 NCManager         : app rtt of 37.526696 to
>> itchy.cs.uga.edu:55904
>> DE 1240415906095 JpcapPinger       : Sending new ping to
>> remoteNode=itchy.cs.uga.edu:55904 using ICMP
>> DE 1240415906095 JpcapPinger       : Creating ICMP ping to
>> itchy.cs.uga.edu:55904
>> DE 1240415906095 JpcapPinger       : Ethernet header for this ICMP
>> ping is jpcap.packet.EthernetPacket@1f0cbfb
>> 00:0b:db:90:c6:97->00:0f:34:56:7b:80 (2048)
>> DE 1240415906095 JpcapPinger       : SENT seq=299 id=5639 orig=0
>> trans=0 recv=0
>> DE 1240415906096 JpcapPinger       : sendPacket [raw=true]=0:0
>> /165.91.83.22->/128.192.101.217 protocol(1) priority(0)  hop(100)
>> offset(0) ident(0)type(8) code(0) sendTS=1240415906095
>> DE 1240415910581 JpcapPinger       : in receivePacket
>> packet=1240415906:127208 /128.192.101.217->/165.91.83.22 protocol(1)
>> priority(0)  hop(50)  offset(0) ident(25984)type(0) code(0)
>> DE 1240415910581 JpcapPinger       : Captured a packet from
>> src=/128.192.101.217
>> DE 1240415910581 JpcapPinger       : Found a matching ping request
>> WA 1240415910729 JpcapPinger       : timeout ident=299
>> Exception in thread "main" java.lang.AssertionError: PingData
>> pd=edu.harvard.syrah.pyxida.ping.JpcapPinger$JpcapPingData@73b72 not
>> found in list: []
>> at
>>
>> edu.harvard.syrah.pyxida.ping.JpcapPinger.removeRequest(JpcapPinger.java:205)
>>
>> at edu.harvard.syrah.pyxida.ping.JpcapPinger$2.cb(JpcapPinger.java:389)
>> at
>>
>> edu.harvard.syrah.sbon.async.CallbacksIF$CB0.callCBResult(CallbacksIF.java:168)
>>
>> at
>>
>> edu.harvard.syrah.sbon.async.CallbacksIF$AbstractCB$1.cb(CallbacksIF.java:71)
>>
>> at edu.harvard.syrah.sbon.async.EL.handleEvent(EL.java:659)
>> at edu.harvard.syrah.sbon.async.EL.handleEventQueues(EL.java:594)
>> at edu.harvard.syrah.sbon.async.EL.main(EL.java:406)
>> at edu.harvard.syrah.pyxida.Pyxida.main(Pyxida.java:191)
>>
>> Another type of error:
>>
>> IN 1240418952240 NCClient          : getNeighborToPing: pinged/non
>> 32/0 avgTimeSincePing 369498.78125 minTime 1
>> IN 1240418952240 NCClient          : getNeighborToPing: lowered
>> MIN_UPDATE_TIME_TO_PING 1
>> IN 1240418952240 NCClient          : getNeighborToPing: picking from
>> grayingNeighbors 32/32 planetlab2.ifi.uio.no:55904
>> DE 1240418952240 NCManager         : getUpNeighbor using up:
>> itchy.cs.uga.edu:55904
>> DE 1240418952241 NCManager         : Sending gossip request to
>> planetlab2.ifi.uio.no:55904
>> WA 1240418952570 ObjComm$ReadConnHa: Received another connection from
>> remoteAddr=planetlab2.ifi.uio.no:55904
>> WA 1240418952571 ObjComm$ReadConnHa: Closing old connection.
>> Exception in thread "main" java.nio.channels.CancelledKeyException
>> at sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:55)
>> at sun.nio.ch.SelectionKeyImpl.readyOps(SelectionKeyImpl.java:69)
>> at edu.harvard.syrah.sbon.async.EL.handleSelectCallbacks(EL.java:770)
>> at edu.harvard.syrah.sbon.async.EL.main(EL.java:434)
>> at edu.harvard.syrah.pyxida.Pyxida.main(Pyxida.java:191)
>>
>> Jonathan Ledlie wrote:
>>
>> I've been using jpcap 0.7 and jdk 1.6.0_11.  I'm fairly sure the
>> jpcap.jar is 0.7.
>>
>> Maybe you should try jpcap outside of Pyxida and see if that works on
>> your system.
>>
>> -jonathan
>>
>> On Apr 14, 2009, at 7:44 AM, Ngo Cao Cuong wrote:
>>
>>
>> Hello,
>>
>> Could you tell me with version of jpcap and jdk you currently use with
>> Pyxida ? Because I've tried compiling with jpcap 0.5.1 source and
>> there's some errors with (with the lastest code of pyxida), I tried the
>> jpcap.rar file (I dont know what version it is) on the CVS repository,
>> no error on compiling but there's a runtime error :
>> "Exception in thread "Thread-2" java.lang.NoSuchMethodError:
>> setRoutingOption
>>  at jpcap.JpcapCaptor.nativeOpenLive(Native Method)
>>  at jpcap.JpcapCaptor.openDevice(JpcapCaptor.java:68)
>>  at
>> edu.harvard.syrah.pyxida.ping.JpcapPinger$1.run(JpcapPinger.java:107)
>>
>> I tried with both jpcap 0.6 and 0.7 on its site but there's the same
>> error.
>> (I use jdk1.6.0_13).
>>
>> Thank you very much for your help.
>>
>> Jonathan Ledlie wrote:
>>
>> Yeah, that's not going to work as is.  We've asked a student at
>> Tsinghua
>> to fix it, but you are welcome to give it a crack.  In the
>> meantime, UDP
>> should work.
>>
>> -jonathan
>>
>> On Apr 7, 2009, at 4:36 PM, Cao Cuong Ngo wrote:
>>
>> I've tried using the version 0.1.5 on the site(both binary and
>> compiling from code) and it doesn't work with Java 1.5 (only work
>> with
>> 1.6).
>> The version 0.1.4 worked with Java 1.5 and jpcap 0.5.1 but the same
>> error SendTS > RecvTS happened to me as 0.1.5.
>> I've also tried with application ping but Vivaldi never converges
>> because of the instability of rtt measurements.
>>
>> Thank you,
>> Cuong.
>>
>> 2009/4/7, Jonathan Ledlie <jon...@ee...>:
>>
>> Using Java 1.5 and jpcap 0.5.1 worked, IIRC.
>>
>> I'd recommend using UDP if possible for the time being.
>>
>> Another Pyxida user is looking into a fix, but if you find one, that
>> would be great.  We haven't looked and I doubt it is a major
>> incompatability.
>>
>> -jonathan
>>
>> On Apr 7, 2009, at 9:27 AM, Peter Pietzuch wrote:
>>
>> Ngo Cao Cuong wrote:
>> I haven't found where we can fix it yet but I'll try.
>> At the moment could you tell me which configuration (of pyxida,
>> jdk,
>> jpcap) we can implement stably on PlanetLab?
>>
>> Jon, what was the last version that ran successfully on PlanetLab
>> with pcap?
>>
>> Cheers,
>> Peter
>>
>> Peter Pietzuch wrote:
>> Ngo Cao Cuong wrote:
>>
>> Thank you for your answer.
>> I installed java 1.6.0_13, I tried jpcap 0.5.1, it did work but
>> everytime the RecvTS is much bigger than SendTS so the
>> latency is
>> very
>> big (like 124535363633), so every node one planetlab update with
>> [0,0,0,0]
>>
>> This is the correct version to use. We are aware of the bug with
>> Java
>> 1.6 and the recvTS/sendTS timestamps but haven't fixed it yet. I
>> think
>> it has something to do with the fact that the resolution of
>> nanoTime has
>> changed in Java 1.6. Can you see if you can fix it?
>>
>> Cheers,
>> Peter
>>
>>
>> Peter Pietzuch wrote:
>>
>> Hello,
>>
>> Ngo Cao Cuong wrote:
>>
>> Well finally I solved this problem (because we need to install
>> java 1.6
>> instead of 1.5!) but there is always an error with jpcap
>> "exception in
>> thread"thread-2" java.lang.nosSuchMethodError:
>> setRoutingOption
>> at jpcap.JpcapCaptor.nativeOpenLive(Native Method)
>> at jpcap.JpcapCaptor.openDevice(JpcapCaptor.java:68)
>> at edu.harvard.syrah.pyxida.ping.JpcapPinger
>> $1.run(JpcapPinger.java:95)
>>
>> This seems like a version conflict between the Java jpcap
>> library and
>> the pcap installation on your machine. Can you check the
>> versions?
>>
>> Cheers,
>> Peter
>>
>>
>> Hello,
>>
>> I've tried to run 0.1.5 but there is always an error:
>> "Exception in thread "main"
>> java.lang.UnsupportedClassVersionError: Bad
>> version number in .class file"
>>
>> I've tried to run 0.1.4 too , it did run but sometimes there
>> is some
>> nodes quit the network with the error of JPcap "RecvTS <
>> SendTS" ???
>> (error on the assert RecvTS > SendTS)
>>
>> Anyone can help me?
>>
>> Thank you,
>> Ngo Cao Cuong
>> INRIA Sophia Antipolis, France.
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>> This SF.net email is sponsored by:
>> High Quality Requirements in a Collaborative Environment.
>> Download a free trial of Rational Requirements Composer Now!
>> http://p.sf.net/sfu/www-ibm-com
>> _______________________________________________
>> Pyxida-users mailing list
>> Pyx...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyxida-users
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>> This SF.net email is sponsored by:
>> High Quality Requirements in a Collaborative Environment.
>> Download a free trial of Rational Requirements Composer Now!
>> http://p.sf.net/sfu/www-ibm-com
>> _______________________________________________
>> Pyxida-users mailing list
>> Pyx...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyxida-users
>>
>>
>> --Dr Peter R Pietzuch
>> Department of Computing, Imperial College London
>> South Kensington Campus, 180 Queen's Gate, London SW7 2AZ, UK
>> Telephone: +44 (20) 7594 8314    http://www.doc.ic.ac.uk/~prp<http://www.doc.ic.ac.uk/%7Eprp>
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>> This SF.net email is sponsored by:
>> High Quality Requirements in a Collaborative Environment.
>> Download a free trial of Rational Requirements Composer Now!
>> http://p.sf.net/sfu/www-ibm-com
>> _______________________________________________
>> Pyxida-users mailing list
>> Pyx...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyxida-users
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>> This SF.net email is sponsored by:
>> High Quality Requirements in a Collaborative Environment.
>> Download a free trial of Rational Requirements Composer Now!
>> http://p.sf.net/sfu/www-ibm-com
>> _______________________________________________
>> Pyxida-users mailing list
>> Pyx...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyxida-users
>>
>>
>>
>>
>>
>> <onelab03.inria.fr.pdf>------------------------------------------------------------------------------
>> Crystal Reports &#45; New Free Runtime and 30 Day Trial
>> Check out the new simplified licensign option that enables unlimited
>> royalty&#45;free distribution of the report engine for externally facing
>> server and web deployment.
>>
>> http://p.sf.net/sfu/businessobjects_______________________________________________
>> Pyxida-users mailing list
>> Pyx...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyxida-users
>>
>>
>>
>>
>

2006	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec (2)
2007	Jan	Feb	Mar (2)	Apr	May (1)	Jun	Jul	Aug	Sep	Oct (1)	Nov	Dec (1)
2008	Jan	Feb	Mar (8)	Apr (13)	May (11)	Jun (8)	Jul (19)	Aug (11)	Sep (18)	Oct (20)	Nov (22)	Dec (50)
2009	Jan (9)	Feb	Mar	Apr (21)	May (1)	Jun	Jul	Aug	Sep	Oct	Nov	Dec

pyxida-users Mailing List for Pyxida

pyxida-users — Pyxida users mailing list for general discussion