# Why block's buffer was mapped to two address **URL:** \ **Category:** GNU Radio\ **Created:** [June 15, 2015, 3:49pm UTC](https://www.ruby-forum.com/t/why-blocks-buffer-was-mapped-to-two-address/242319 "2015-06-15T15:49:54Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Detlef\_R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/58f4c7/32.png) [@Detlef\_R](https://www.ruby-forum.com/u/Detlef_R)\ **Post date:** [June 15, 2015, 3:49pm UTC](https://www.ruby-forum.com/t/why-blocks-buffer-was-mapped-to-two-address/242319/1 "2015-06-15T15:49:54Z")
Hi, I found block’s buffer was mapped to two continues address, is there any benefit for this? When do update reader/writer pointer, I found they was rounded to the real buffer size, so I want to know which code will use this second half address? – Thanks Tiankun ---
**Author:** ![Tiankun\_Hu](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/46a35a/32.png) [@Tiankun\_Hu](https://www.ruby-forum.com/u/Tiankun_Hu)\ **Post date:** [June 15, 2015, 4:05pm UTC](https://www.ruby-forum.com/t/why-blocks-buffer-was-mapped-to-two-address/242319/2 "2015-06-15T16:05:05Z")
Hi Tiankun Hu, I hope I’m answering the right question, but: gr-buffer maps the same pages into memory multiple times, forming a pseudo-ring buffer, so that no matter where in your buffer you start, you always get the full buffer length of “sequential data”. This is very cool for algorithms that expect consecutive samples, because there’s no need to find out where the next sample lies – it’s always at the address right after the last one. To achieve that, GNU Radio gets pages that can be memory-mapped. For example, under Linux, we get shared memory segments, and then mmap() multiple times, right after the last mapping. > When do update reader/writer pointer, I found they was rounded to the > real buffer size, so I want to know which code will use this second > half address? > For example, your Buffer looks like the following: > W = 1kB written by the upstream block, unread (not consume()d) by the > downstream block > R = 1kB already consumed by the downstream block: W R R R W W so your read pointer is at the beginning of the fifth kilobyt: W R R R W W ^ read pointer Now , we’d like to let the reading block read the whole unread items at once, i.e. all three W kilobytes. We simply do that by mapping a second copy right after the first: W R R R W W|W R R R W W ^ read pointer After that call, the situation is: W W W W W W|W W W W W W ^ read pointer Of course, this isn’t cool – the read pointer should always be within the buffer size, so we simply do a modulo buffer length : W W W W W W|W W W W W W ^ read pointer Best regards, Marcus ---
**Author:** ![Tiankun\_Hu](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/46a35a/32.png) [@Tiankun\_Hu](https://www.ruby-forum.com/u/Tiankun_Hu)\ **Post date:** [June 16, 2015, 7:07am UTC](https://www.ruby-forum.com/t/why-blocks-buffer-was-mapped-to-two-address/242319/3 "2015-06-16T07:07:08Z")
Hi Marcus, Thanks your reply, I got it, it is really cool. If just mapped to one address, in general\_work function user need to consider whether R/W pointer has out of buffer size, right? ------------------ Original ------------------ From: “Marcus M.”;[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid); Date: Mon, Jun 15, 2015 10:03 PM To: "discuss-gnuradio"[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid); Subject: Re: [Discuss-gnuradio] why block’s buffer was mapped to two address Hi Tiankun Hu, I hope I’m answering the right question, but: gr-buffer maps the same pages into memory multiple times, forming a pseudo-ring buffer, so that no matter where in your buffer you start, you always get the full buffer length of “sequential data”. This is very cool for algorithms that expect consecutive samples, because there’s no need to find out where the next sample lies – it’s always at the address right after the last one. To achieve that, GNU Radio gets pages that can be memory-mapped. For example, under Linux, we get shared memory segments, and then mmap() multiple times, right after the last mapping. > When do update reader/writer pointer, I found they was rounded to the > real buffer size, so I want to know which code will use this second > half address? > For example, your Buffer looks like the following: > W = 1kB written by the upstream block, unread (not consume()d) by the > downstream block > R = 1kB already consumed by the downstream block: W R R R W W so your read pointer is at the beginning of the fifth kilobyt: W R R R W W ^ read pointer Now , we’d like to let the reading block read the whole unread items at once, i.e. all three W kilobytes. We simply do that by mapping a second copy right after the first: W R R R W W|W R R R W W ^ read pointer After that call, the situation is: W W W W W W|W W W W W W ^ read pointer Of course, this isn’t cool – the read pointer should always be within the buffer size, so we simply do a modulo buffer length : W W W W W W|W W W W W W ^ read pointer Best regards, Marcus ---
**Author:** ![Tiankun\_Hu](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/46a35a/32.png) [@Tiankun\_Hu](https://www.ruby-forum.com/u/Tiankun_Hu)\ **Post date:** [June 16, 2015, 3:34pm UTC](https://www.ruby-forum.com/t/why-blocks-buffer-was-mapped-to-two-address/242319/4 "2015-06-16T15:34:48Z")
On Tue, Jun 16, 2015 at 1:05 AM, Tiankun Hu [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Hi Marcus, > Thanks your reply, I got it, it is really cool. > If just mapped to one address, in general\_work function user need to > consider whether R/W pointer has out of buffer size, right? I wrote up a presentation explaining the stages of the scheduler in more depth: > **[Explaining the GNU Radio Scheduler — Rondeau Research](http://www.trondeau.com/blog/2013/9/15/explaining-the-gnu-radio-scheduler.html)** > > The most important and distinguishing piece of GNU Radio is the underlying scheduler and framework for implementing and connecting the signal processing blocks. While there are many other libraries of DSP blocks available, it's GNU Radio's scheduler... Tom