On Monday 07 March 2011 22:00:25 hlabishi kobo wrote:
Linus suggested to me that i should print the window and see how it looks, I did that and it returns this ef0fffffe, ffbffff, f70fffff, eb1b53c0, eb3950b8, eb1749c0. I am not sure if this are hexadecimal number or what.
I would think that you wrote the part which prints out this values. This means that you know which parameters you gave printk and that you should know the conversation specifiers and length modifiers that you used in the format string.
But I would guess without having any of these information that you used %x to print these values. Whatever you used as argument - 32 bit (size of single int) of it were printed in unsigned in hexidecimal notation. Maybe you should think about using %lx to print unsigned long ints in hexidecimal notation in case you really used %x.
Which brings me to another question: Why to I see 6 numbers in your post and why has the first one 9 nibbles?
As said before (and also recommended by Linus): try to write a small c program which uses these values, print the single bits, try to write some test algorithm using these decoded bits and play a little bit around with other test inputs before trying random things inside the kernel.
Again this is the results of printing seq_bits, so far i have not been able to print real_bits as this cannot even make a network ping. Could you enlighten me in this case.
I cannot understand how pings and printks are related...
May I ask how these things are related to your work/studies? It is ok to play around a little bit as small side project/hobby without having the time and knowledge to understand what you are really doing. That is usually a good way to find new interesting topics and maybe to learn something (or blow up a building...). But I would highly recommend to switch the topic in case this is part of your thesis or work.
It is not meant as harsh criticism of what you try to do, but it seems that right now you aren't able to efficiently work with it and to gain enough knowledge by yourself to be able to understand simple parts the thing you are working with.
Best regards, Sven
Hi thank you very much for your suggestions Sven, they were really helpful. i actually now put the below code down which i am still busy trying to test it.
int weighted_bit_packet_count(TYPE_OF_WORD *seq_bits) { int i,check, count = 0; int j; //TYPE_OF_WORD *word; int word;
for (i = 0; i < NUM_WORDS; i++) { word = seq_bits[i]; for (j = 0; j < 32; j++){ check = (word & (1 << j)) >> j; if (check == 1) count += j; } printk("our count is %d\n", count); return count; } //printk("our count is %d\n", count); //return count; } When i am using it on two PC's my ping seems to be recording much delay. I will appreciate your feedback in this regard. Thank you and kind Regards Hlabishi
On 3/8/11, Sven Eckelmann sven@narfation.org wrote:
On Monday 07 March 2011 22:00:25 hlabishi kobo wrote:
Linus suggested to me that i should print the window and see how it looks, I did that and it returns this ef0fffffe, ffbffff, f70fffff, eb1b53c0, eb3950b8, eb1749c0. I am not sure if this are hexadecimal number or what.
I would think that you wrote the part which prints out this values. This means that you know which parameters you gave printk and that you should know the conversation specifiers and length modifiers that you used in the format string.
But I would guess without having any of these information that you used %x to print these values. Whatever you used as argument - 32 bit (size of single int) of it were printed in unsigned in hexidecimal notation. Maybe you should think about using %lx to print unsigned long ints in hexidecimal notation in case you really used %x.
Which brings me to another question: Why to I see 6 numbers in your post and why has the first one 9 nibbles?
As said before (and also recommended by Linus): try to write a small c program which uses these values, print the single bits, try to write some test algorithm using these decoded bits and play a little bit around with other test inputs before trying random things inside the kernel.
Again this is the results of printing seq_bits, so far i have not been able to print real_bits as this cannot even make a network ping. Could you enlighten me in this case.
I cannot understand how pings and printks are related...
May I ask how these things are related to your work/studies? It is ok to play around a little bit as small side project/hobby without having the time and knowledge to understand what you are really doing. That is usually a good way to find new interesting topics and maybe to learn something (or blow up a building...). But I would highly recommend to switch the topic in case this is part of your thesis or work.
It is not meant as harsh criticism of what you try to do, but it seems that right now you aren't able to efficiently work with it and to gain enough knowledge by yourself to be able to understand simple parts the thing you are working with.
Best regards, Sven
On Thursday 17 March 2011 23:40:06 hlabishi kobo wrote:
Hi thank you very much for your suggestions Sven, they were really helpful. i actually now put the below code down which i am still busy trying to test it.
int weighted_bit_packet_count(TYPE_OF_WORD *seq_bits) { int i,check, count = 0; int j; //TYPE_OF_WORD *word; int word;
for (i = 0; i < NUM_WORDS; i++) { word = seq_bits[i];
for (j = 0; j < 32; j++){ check = (word & (1 << j)) >> j; if (check == 1) count += j; }printk("our count is %d\n", count); return count; } //printk("our count is %d\n", count); //return count; } When i am using it on two PC's my ping seems to be recording much delay. I will appreciate your feedback in this regard. Thank you and kind Regards
Ehrm, you know that you ignore the fact that seq_bits[i] may be 64 bits? And you only calculate the weighted sum of a single "word" (which you static casted to int....?) and not all words. And the sum is still wrong weighted (you still give zero weight for the newest one and increase the weight for the older). And the way you check the bits is even for a sequential implementation overly complex. And it is normal that printk heavily increase the amount of time... maybe you meant that by delay.
Sry, I have really no idea what I should say to it.
Regards, Sven
On 3/18/11, Sven Eckelmann sven@narfation.org wrote:
On Thursday 17 March 2011 23:40:06 hlabishi kobo wrote:
Hi thank you very much for your suggestions Sven, they were really helpful. i actually now put the below code down which i am still busy trying to test it.
int weighted_bit_packet_count(TYPE_OF_WORD *seq_bits) { int i,check, count = 0; int j; //TYPE_OF_WORD *word; int word;
for (i = 0; i < NUM_WORDS; i++) { word = seq_bits[i];
for (j = 0; j < 32; j++){ check = (word & (1 << j)) >> j; if (check == 1) count += j; }printk("our count is %d\n", count); return count; } //printk("our count is %d\n", count); //return count; } When i am using it on two PC's my ping seems to be recording much delay. I will appreciate your feedback in this regard. Thank you and kind Regards
Thank you very much Sven. Your feedback have been really helpful.
Ehrm, you know that you ignore the fact that seq_bits[i] may be 64 bits?
I actually printed the seq_bits[i] and that is basically why i used 32 but that was just for debugging purpose. But actually if i use NUM_WORDS, my weighted sum become very small whereas if i use 32 it becomes very big, trying to understand what might be causing it to be that way. And
you only calculate the weighted sum of a single "word" (which you static casted to int....?) and not all words.
i actually dont understand this very well, how many words does seq_bits[i] have? And the sum is still wrong weighted
(you still give zero weight for the newest one and increase the weight for the older).
Thanks for letting alerting me about this, i hv now changed from ascending to descending order. And the way you check the bits is even for a sequential
implementation overly complex. And it is normal that printk heavily increase the amount of time... maybe you meant that by delay.
even if i comment out the printk() statement its still carries with the delay.
Sry, I have really no idea what I should say to it.
Regards, Sven
Kind Regards Hlabishi
On Monday 21 March 2011 23:40:57 hlabishi kobo wrote: [...]
I actually printed the seq_bits[i] and that is basically why i used 32 but that was just for debugging purpose. But actually if i use NUM_WORDS, my weighted sum become very small whereas if i use 32 it becomes very big, trying to understand what might be causing it to be that way.
NUM_WORDS == amount of unsigned long/words WORD_BIT_SIZE == amount of bits in a unsigned long TQ_LOCAL_WINDOW_SIZE == sum of bits in seq_bits
Nothing really fancy here.
you only calculate the weighted sum of a single "word" (which you static casted to int....?) and not all words.
i actually dont understand this very well, how many words does seq_bits[i] have?
a single "word"/unsigned long. seq_bits consist of NUM_WORDS words (words are defined in context of seq_bits as unsigned long - that's why we removed TYPE_OF_WORD completely and just use unsigned long).
Regards, Sven
Thank you very much Sven, your feedback was very helpful. i ended up with the code below which i am still testing.
int weighted_bit_packet_count(TYPE_OF_WORD *seq_bits) { int i,check, count = 0; TYPE_OF_WORD word;
for (i = 0; i < NUM_WORDS; i++) { word = seq_bits[i]; int j = WORD_BIT_SIZE, k = 1;
while (j > 0 && k <= 32){ check = (word & (1 << j)) >> j; if (check == 1) count += k; j--; k++; } } return count; }
Kind Regards Hlabishi
On 3/22/11, Sven Eckelmann sven@narfation.org wrote:
On Monday 21 March 2011 23:40:57 hlabishi kobo wrote: [...]
I actually printed the seq_bits[i] and that is basically why i used 32 but that was just for debugging purpose. But actually if i use NUM_WORDS, my weighted sum become very small whereas if i use 32 it becomes very big, trying to understand what might be causing it to be that way.
NUM_WORDS == amount of unsigned long/words WORD_BIT_SIZE == amount of bits in a unsigned long TQ_LOCAL_WINDOW_SIZE == sum of bits in seq_bits
Nothing really fancy here.
you only calculate the weighted sum of a single "word" (which you static casted to int....?) and not all words.
i actually dont understand this very well, how many words does seq_bits[i] have?
a single "word"/unsigned long. seq_bits consist of NUM_WORDS words (words are defined in context of seq_bits as unsigned long - that's why we removed TYPE_OF_WORD completely and just use unsigned long).
Regards, Sven
hlabishi kobo wrote:
int weighted_bit_packet_count(TYPE_OF_WORD *seq_bits) { int i,check, count = 0; TYPE_OF_WORD word;
for (i = 0; i < NUM_WORDS; i++) { word = seq_bits[i]; int j = WORD_BIT_SIZE, k = 1;
while (j > 0 && k <= 32){
it is wrong to assume that unsigned long is 32 bit long.
check = (word & (1 << j)) >> j; if (check == 1) count += k; j--; k++;
I would doubt that it is correct to give every set bit the same weight when they have the the distance of sizeof(unsigned long)*8. And I cannot find a good reason why an "old" unsigned long should get the same weights as the "newest" unsigned long - at least not when the actual weights should be reduced for "older" bits in a single unsigned long and the overall weights should be monotonic decreasing with the age. And using WORD_BIT_SIZE for j is like assuming that we only have a single unsigned long in seq_bits... which is not true for many architectures.
And the code is overly complicated without any good reason.
Kind regards, Sven
On 4/3/11, Sven Eckelmann sven@narfation.org wrote:
hlabishi kobo wrote:
int weighted_bit_packet_count(TYPE_OF_WORD *seq_bits) { int i,check, count = 0; TYPE_OF_WORD word;
for (i = 0; i < NUM_WORDS; i++) { word = seq_bits[i]; int j = WORD_BIT_SIZE, k = 1;
while (j > 0 && k <= 32){it is wrong to assume that unsigned long is 32 bit long.
I would doubt that it is correct to give every set bit the same weight when they have the the distance of sizeof(unsigned long)*8. And I cannot find a good reason why an "old" unsigned long should get the same weights as the "newest" unsigned long - at least not when the actual weights should be reduced for "older" bits in a single unsigned long and the overall weights should be monotonic decreasing with the age.
I am looking at how i can deal with this part. And using WORD_BIT_SIZE for j
is like assuming that we only have a single unsigned long in seq_bits... which is not true for many architectures.
During the debugging i realized that this can handle more than 1 unsigned long in seq_bits, i just need to prioritize the newer ones to the old.
And the code is overly complicated without any good reason.
I also thought so but so that it was the simplest i could come with, still drawing up some other ways hopefully i will improve it with time.
Kind regards, Sven
I have been doing some tests using iperf/jperf to simulate traffic between host. The results show lot of packet loss (though inconsistent) and i am not sure if this could be the results of overheads in the network. Is there anyway i could debug the amounts of overheads on the network? What testing methods do you and your team use?
b.a.t.m.a.n@lists.open-mesh.org
-
hlabishi kobo -
Sven Eckelmann