[GNUnet-developers] Re: GNUnet-developers Digest, Vol 17, Issue 3

[OZGUR TAS]

hello,
this key in /root (daemon) kernel operation..
is was loaded linux kernel static ?
default key; (root)

usage: keytab-lilo [ -p old_code=new_code ] ...
   [path]default_layout[.map] ] [path]kbd_layout[.map]

make is prefaring tools, don't kernel static updated.
good working,

Ozgur KARATAS
Is.NET

----- Original Message -----
Kimden: address@hidden
Tarih: Pazartesi, Nisan 5, 2004 8:37 pm
Konu: GNUnet-developers Digest, Vol 17, Issue 3

> Send GNUnet-developers mailing list submissions to
>       address@hidden
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>       http://mail.gnu.org/mailman/listinfo/gnunet-developers
> or, via email, send a message with subject or body 'help' to
>       address@hidden
> 
> You can reach the person managing the list at
>       address@hidden
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of GNUnet-developers digest..."
> 
> 
> Today's Topics:
> 
>   1. compile error with libgcrypt (Glenn McGrath)
>   2. Re: compile error with libgcrypt (Christian Grothoff)
>   3. Re: compile error with libgcrypt (Glenn McGrath)
>   4. [PATCH] Addition of More autoconf Checks (Alexander Winston)
>   5. Re: [PATCH] Addition of More autoconf Checks (Christian 
> Grothoff)   6. high disk-io (Christian)
>   7. Re: high disk-io (Christian Grothoff)
> 
> 
> --------------------------------------------------------------------
> --
> 
> Message: 1
> Date: Sun, 4 Apr 2004 11:55:49 +1000
> From: Glenn McGrath <address@hidden>
> Subject: [GNUnet-developers] compile error with libgcrypt
> To: address@hidden
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=US-ASCII
> 
> Im getting a compile error compile GNunet 0.6.1d against libgcrypt,
> tried v1.1.90 and 1.1.93
> 
> hostkey_gcrypt.c: In function `encodeHostkey':
> hostkey_gcrypt.c:359: error: structure has no member named `key'
> hostkey_gcrypt.c:364: error: structure has no member named `key'
> hostkey_gcrypt.c:369: error: structure has no member named `key'
> hostkey_gcrypt.c:375: error: structure has no member named `key'
> hostkey_gcrypt.c:380: error: structure has no member named `key'
> hostkey_gcrypt.c:386: error: structure has no member named `key'
> hostkey_gcrypt.c: In function `decodeHostkey':
> hostkey_gcrypt.c:412: error: structure has no member named `key'
> hostkey_gcrypt.c:425: error: structure has no member named `key'
> hostkey_gcrypt.c:439: error: structure has no member named `key'
> hostkey_gcrypt.c:456: error: structure has no member named `key'
> hostkey_gcrypt.c:475: error: structure has no member named `key'
> hostkey_gcrypt.c:499: error: structure has no member named `key'
> 
> I had a very quick look at it, not sure what the key field should be
> refering to.
> 
> 
> Glenn
> 
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Sat, 3 Apr 2004 21:35:09 -0500
> From: Christian Grothoff <address@hidden>
> Subject: Re: [GNUnet-developers] compile error with libgcrypt
> To: address@hidden
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Krista forgot some trivial casts since she did not try compiling 
> with 
> libgcrypt (and neither did anyone else).  Patch is attached (and in 
> CVS).
> C
> 
> On Saturday 03 April 2004 20:55, Glenn McGrath wrote:
> > Im getting a compile error compile GNunet 0.6.1d against libgcrypt,
> > tried v1.1.90 and 1.1.93
> >
> > hostkey_gcrypt.c: In function `encodeHostkey':
> > hostkey_gcrypt.c:359: error: structure has no member named `key'
> > hostkey_gcrypt.c:364: error: structure has no member named `key'
> > hostkey_gcrypt.c:369: error: structure has no member named `key'
> > hostkey_gcrypt.c:375: error: structure has no member named `key'
> > hostkey_gcrypt.c:380: error: structure has no member named `key'
> > hostkey_gcrypt.c:386: error: structure has no member named `key'
> > hostkey_gcrypt.c: In function `decodeHostkey':
> > hostkey_gcrypt.c:412: error: structure has no member named `key'
> > hostkey_gcrypt.c:425: error: structure has no member named `key'
> > hostkey_gcrypt.c:439: error: structure has no member named `key'
> > hostkey_gcrypt.c:456: error: structure has no member named `key'
> > hostkey_gcrypt.c:475: error: structure has no member named `key'
> > hostkey_gcrypt.c:499: error: structure has no member named `key'
> >
> > I had a very quick look at it, not sure what the key field should be
> > refering to.
> >
> >
> > Glenn
> >
> >
> > _______________________________________________
> > GNUnet-developers mailing list
> > address@hidden
> > http://mail.gnu.org/mailman/listinfo/gnunet-developers
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: hostkey_gcrypt.patch
> Type: text/x-diff
> Size: 2925 bytes
> Desc: not available
> Url : http://mail.gnu.org/pipermail/gnunet-developer
> 
> ------------------------------
> 
> Message: 3
> Date: Sun, 4 Apr 2004 12:55:19 +1000
> From: Glenn McGrath <address@hidden>
> Subject: Re: [GNUnet-developers] compile error with libgcrypt
> To: address@hidden
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=US-ASCII
> 
> On Sat, 3 Apr 2004 21:35:09 -0500
> Christian Grothoff <address@hidden> wrote:
> 
> > Krista forgot some trivial casts since she did not try compiling 
> with 
> > libgcrypt (and neither did anyone else).  Patch is attached (and in
> > CVS).
> 
> Thanks, that fixes that problem.
> 
> Working on debian packages now.
> 
> 
> Glenn
> 
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Mon, 05 Apr 2004 08:54:09 -0400
> From: Alexander Winston <address@hidden>
> Subject: [GNUnet-developers] [PATCH] Addition of More autoconf Checks
> To: address@hidden
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset="us-ascii"
> 
> Skipped content of type multipart/mixed-------------- next part ----
> ----------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 189 bytes
> Desc: This is a digitally signed message part
> Url : http://mail.gnu.org/pipermail/gnunet-developer
> 
> ------------------------------
> 
> Message: 5
> Date: Mon, 5 Apr 2004 09:42:46 -0500
> From: Christian Grothoff <address@hidden>
> Subject: Re: [GNUnet-developers] [PATCH] Addition of More autoconf
>       Checks
> To: address@hidden
> Message-ID: <address@hidden>
> Content-Type: text/plain;  charset="iso-8859-1"
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Monday 05 April 2004 07:54 am, Alexander Winston wrote:
> > I ran autoupdate and autoscan in the top-level directory and they
> > suggested a few changes and additions, respectively.
> 
> Yes, but some of these are known to cause problems -- like the 
> MALLOC/REALLOC 
> check (which checks for a certain *style* of malloc, which GNUnet 
> does not 
> rely on -- and which would make GNUnet no longer compile on certain 
> systems 
> that do not have that malloc style).  autoscan may make 
> suggestions, but 
> they're sometimes problematic.
> 
> > I minded the
> > suggestions and then divided the one big patch into four smaller 
> ones:> compiler checks, header checks, function checks, and the 
> changes> suggested by autoupdate. Except for the autoupdate patch, 
> all of the
> > applicable sections were sorted alphabetically for increased
> > readability. I hope that this does not matter.
> >
> > For better or worse, I'm still an autoconf newbie. Therefore, 
> none of
> > these might be useful. However, I tested them on my Debian 
> GNU/Linux Sid
> > box and did not notice any problems.
> 
> Right, but the whole point of configure is to make it portable.  
> Since your 
> changes won't improve portability (and in fact some of them are 
> known to 
> break portability), I don't think they should be applied. In fact, 
> instead of 
> increasing just the number of mindless tests that are done, what we 
> should do 
> is remove tests that we're not using later (that is, either fail on 
> the test 
> or depend on a conditional set by the test, but not like now do a 
> bunch of 
> tests that have no impact at all but lengthen the compile time).
> 
> Christian
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
> 
> iD8DBQFAcXBm9tNtMeXQLkIRAtS3AJ4gnnKCr5rRGTrE0rwv4GlnxHkqRwCeKT6Q
> 1VLzWGWlpgIFnBLqv0uoPlw=
> =/KrX
> -----END PGP SIGNATURE-----
> 
> 
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Mon, 5 Apr 2004 23:57:14 +0900
> From: Christian <address@hidden>
> Subject: [GNUnet-developers] high disk-io
> To: "address@hidden" <address@hidden>
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=euc-jp
> 
> 
> I saw this was a subject allready before. Since in my case gnunetd 
> often got really agressive on the disk for hours i started to 
> spread debug messages accross the manager, routing and migration code.
> 
> There are many points which i just assume gnunet-behaviour so 
> please correct me if somethings wrong. 
> Whenever a package is about to leave the node it will be checked 
> for padding space (up to MTU of the transport). If that space is 
> bigger than about 1K (i guess less doesnt make sense) we start to 
> pick random content to fill in that gap. (activeMigration) This 
> data seems to be really random and not picked up as a linear stream 
> or from a buffer.
> According to what i see in my logfile most disk io is generated by 
> migration (roughly 80% i guess). Since many things are indexed here 
> there is lots of on-demand encoding. But i dont think this is much 
> different to inserted content at this point. (is it?)
> Now i had gnunetd running just for a couple of minutes with the 
> debug output but i think it will not change much over the time.
> 
> Conditions under which gnunetd is running here:
> MySQL (1024MB)
> free sais 100MB cached (its a small machine)
> 90000 (set as up & down bandwidth in config file)
> 
> I think there should be similar way of control be used for disk-io 
> like for CPU and network load. To reduce padding at first and if it 
> is not enough to reduce even query lookups.
> 
>  Chris
> 
> 
> 
> 
> ------------------------------
> 
> Message: 7
> Date: Mon, 5 Apr 2004 12:32:39 -0500
> From: Christian Grothoff <address@hidden>
> Subject: Re: [GNUnet-developers] high disk-io
> To: address@hidden
> Message-ID: <address@hidden>
> Content-Type: text/plain;  charset="euc-jp"
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Monday 05 April 2004 09:57 am, Christian wrote:
> >  I saw this was a subject allready before. Since in my case 
> gnunetd often
> > got really agressive on the disk for hours i started to spread debug
> > messages accross the manager, routing and migration code.
> >
> > There are many points which i just assume gnunet-behaviour so please
> > correct me if somethings wrong. Whenever a package is about to 
> leave the
> > node it will be checked for padding space (up to MTU of the 
> transport). If
> > that space is bigger than about 1K (i guess less doesnt make 
> sense) we
> > start to pick random content to fill in that gap. 
> (activeMigration) This
> > data seems to be really random and not picked up as a linear 
> stream or from
> > a buffer. According to what i see in my logfile most disk io is 
> generated> by migration (roughly 80% i guess). Since many things 
> are indexed here
> > there is lots of on-demand encoding. But i dont think this is much
> > different to inserted content at this point. (is it?) Now i had 
> gnunetd> running just for a couple of minutes with the debug output 
> but i think it
> > will not change much over the time.
> 
> Your description of what is going on is correct.  I find it 
> interesting that 
> 80% of disk IO is activemigration, I had suspected it would be much 
> less (but 
> I don't have any numbers and you do :-).  Which gives us an 
> interesting 
> handle on the issue (if true in general).
> 
> > Conditions under which gnunetd is running here:
> > MySQL (1024MB)
> > free sais 100MB cached (its a small machine)
> > 90000 (set as up & down bandwidth in config file)
> >
> >  I think there should be similar way of control be used for disk-
> io like
> > for CPU and network load. To reduce padding at first and if it is 
> not> enough to reduce even query lookups.
> 
> Actually, there is one additional possibility, which is to make the 
> disk-io 
> less random.  If, for example, we gather more than just one block 
> at a time 
> from a file and instead read a dozen or two (possibly in sequence), 
> that does 
> not increase IO much but improves throughput dramatically.  The bad 
> news is 
> that it also makes deniability worse since chances of a peer that 
> does not 
> have the file pushing out closely related blocks from a presumably 
> 'random' 
> assembly of migrated blocks are low.  Anyway, together with the 
> buffering of 
> content by the active-migration thread (may cost memory) it should 
> be 
> possible to achieve an acceptable trade-off that can still be 
> better than 
> just not doing migration.
> 
> But for all three approaches to lower IO, we first need some code 
> to measure 
> how much (actual) IO is going on -- otherwise the code would not 
> know when to 
> throttle.
> 
> Thanks for the data-point, I'll definitely keep it in mind (though 
> I have my 
> doubts that it holds for machines with less bandwidth, but then 
> again, those 
> may also not have problems with the IO load...)
> 
> Christian
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
> 
> iD8DBQFAcZg69tNtMeXQLkIRAr1XAJwO413CReopA9PitvmTldplQ7Hx6ACaAtNm
> qHcvl3PA+XnRBfUnLUa31UE=
> =6ZCj
> -----END PGP SIGNATURE-----
> 
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnunet-developers
> 
> 
> End of GNUnet-developers Digest, Vol 17, Issue 3
> ************************************************
>