gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [GNUnet-developers] gnunet download problem


From: eric haumant
Subject: RE: [GNUnet-developers] gnunet download problem
Date: Tue, 1 Apr 2003 17:30:52 +0200

I don't know if it can help solving the problem but : 
 - I'm testing the gnunet download without activemigration and the deadlock
seems to have disappeared. 
 - For the moment, it has downloaded 50Mo within less than 2 hours (I think
8.5kbytes/s on average).

Eric.


-----Message d'origine-----
De : Christian Grothoff [mailto:address@hidden
Envoyé : vendredi 28 mars 2003 11:26
À : eric haumant
Cc : address@hidden
Objet : Re: [GNUnet-developers] gnunet download problem


Neither nor. It's a deadlock of the request manager when it attempts to 
suspend the cron thread. I don't know yet why it happens, but this is the 
real cause. No routing problem, definitely not. The *client* process just 
hangs itself.

Christian

(gdb) thread 6
[Switching to thread 6 (Thread 4101 (LWP 30178))]#0  0x40409906 in
sigsuspend 
() from /lib/libc.so.6
(gdb) ba
#0  0x40409906 in sigsuspend () from /lib/libc.so.6
#1  0x403047f0 in __pthread_wait_for_restart_signal () from 
/lib/libpthread.so.0
#2  0x40300f3d in pthread_cond_wait () from /lib/libpthread.so.0
#3  0x402b7420 in semaphore_down_ (s=0x86c3db8, filename=0x402ba9e0
"cron.c", 
linenumber=310) at semaphore.c:202
#4  0x402b2dce in suspendCron () at cron.c:310
#5  0x402a2442 in requestManagerReceive (this=0x80a3a78, msg=0x8685f40) at 
requestmanager.c:442
#6  0x402a1ffa in receiveThread (this=0x80a3a78) at requestmanager.c:305
#7  0x40301f37 in pthread_start_thread () from /lib/libpthread.so.0



On Donnerstag, 27. März 2003 05:53 you wrote:
> Hello,
>
> I don't think the problem comes from the routing part because it happened
> to me while gnunet-download was checking that the block was already
> downloaded. It happened to me more and more frequently while the download
> goes to the end.
>
> I can see that gnunet-download stops when the memory use fails to just
> 350kb and some times the local gnunetd fails with it and I have to restart
> gnunetd and gnunet-download.
> When gnunet-download checks the block's presence, I have some breakpoint's
> error, is it normal ?
>
> > One thing certain is that atleast with the current implementation,
> > it will never be blazing fast, even if it worked correctly. A thing
> > worth mentioning anyway is that if you limit your upstream, that
> > will affect the download speed as well, as the node will drop
> > excess outgoing packets, even those containing your queries.
>
> I've mesured a download speed of 4kb/s on average which is low enought for
> people with only 56k modem.
>
> Thanks,
> Eric.
>
>
> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnunet-developers





reply via email to

[Prev in Thread] Current Thread [Next in Thread]