date:20141119

Re: [riot-devel] vtimer in native port

2014-11-19 Thread Ludwig Ortmann

Hi,

On Wed, Nov 19, 2014 at 05:12:42PM +, Hiesgen, Raphael wrote:
> Hey there,
> 
> more questions! We encountered some problems using vtimer.  For once, setting 
> multiple short timers consecutively leads to a segfault. We tired this with 
> the timer_msg test reducing the intervals to around 150ms.
> 
> A second problem showed up when setting multiple timers at once, e.g., from 
> different threads. After a short time the "timer is already due” warning from 
> schedule timer in hwtimer_cpu.c flashed and soon after the timers simply 
> stopped.
> 
> So, I am not sure if these problems originate in our own implementation or 
> the native port. In order to test the short timers, we executed the same 
> program on the iot-lab_M3 board, where it worked even with much shorter 
> timers. 
> 
> Anything I should know?

There is some problem I didn't get around to fixing, yes.
I guess your issue it is related to this:
https://github.com/RIOT-OS/RIOT/issues/715

Cheers, Ludwig
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] vtimer in native port

2014-11-19 Thread Hiesgen, Raphael

Hey there,

more questions! We encountered some problems using vtimer.  For once, setting 
multiple short timers consecutively leads to a segfault. We tired this with the 
timer_msg test reducing the intervals to around 150ms.

A second problem showed up when setting multiple timers at once, e.g., from 
different threads. After a short time the "timer is already due” warning from 
schedule timer in hwtimer_cpu.c flashed and soon after the timers simply 
stopped.

So, I am not sure if these problems originate in our own implementation or the 
native port. In order to test the short timers, we executed the same program on 
the iot-lab_M3 board, where it worked even with much shorter timers. 

Anything I should know?

Thanks
Raphael
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Dedicated RIOT Testing Meeting

2014-11-19 Thread Philipp Rosenkranz

Hi everyone,

the minutes of the meeting are now available at:

https://github.com/RIOT-OS/RIOT/wiki/Virtual-testing-meeting-on-November-19%2C-2014

Please feel free to comment and edit if you think I missed anything or
something is unclear.

Best regards,
Philipp



2014-11-19 15:21 GMT+01:00 Philipp Rosenkranz <
philipp.rosenkr...@fu-berlin.de>:

> Yes, I will provide a link to the minutes soon.
>
> 2014-11-19 15:17 GMT+01:00 Martine Lenders :
>
>> Hi,
>> Sorry I couldn't attend. Will there be minutes?
>>
>> Cheers,
>> Martine
>> Am 19.11.2014 12:58 schrieb "Oleg Hahm" :
>>
>> Here goes the PlaceCame link:
>>>
>>> http://placecam.de/call.php?c=VBYEpXi43MZ2MOrV~pegsMm6Z7woUbw.VRY0Qxal2pE-
>>>
>>> Am Tue, Nov 11, 2014 at 09:13:23PM +0100 schrieb Philipp Rosenkranz:
>>> > Hi everyone,
>>> >
>>> > I'd like to announce that the dedicated RIOT testing meeting will take
>>> > place on:
>>> >
>>> > Wednesday the 19th of November at 01:00 pm CET.
>>> >
>>> >
>>> > We will use PlaceCam for the meeting. If you are using Linux you need
>>> to
>>> > install
>>> > PlaceCam beforehand. PlaceCam can be found at [1].
>>> > Please note that you don't need to create an PlaceCam account.
>>> > Access to the conference call will be provided by a link which I will
>>> share
>>> > on this
>>> > list shortly before the meeting starts.
>>> >
>>> > [1] http://www.daviko.com/videokonferenz/3-1-Download.html
>>> >
>>> >
>>> > Best regards,
>>> > Philipp
>>>
>>> > ___
>>> > devel mailing list
>>> > devel@riot-os.org
>>> > http://lists.riot-os.org/mailman/listinfo/devel
>>>
>>>
>>> --
>>> /* Ugly, ugly fucker. */
>>> linux-2.6.6/include/linux/netfilter_ipv4/ipt_limit.h
>>>
>>> ___
>>> devel mailing list
>>> devel@riot-os.org
>>> http://lists.riot-os.org/mailman/listinfo/devel
>>>
>>>
>> ___
>> devel mailing list
>> devel@riot-os.org
>> http://lists.riot-os.org/mailman/listinfo/devel
>>
>>
>
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Hack'n'ACK - Part V - The Pull Requests Strike Back

2014-11-19 Thread Martine Lenders

Dear Hack'n'ACKers,

There are again over 100 Pull Requests open so lets do another Hack'n'ACK.
According to our Dudle [1] and in correspondence with the guys from c-base,
our next meeting will on

Tue, November 25th 2014 at 17:00 CET in the "Seminarraum" at the c-base

The c-base is at Rungestraße 20, 10179 Berlin. A map how to get there can
be found here [3].

We try to make remote participation via PlaceCam [4] possible, but since we
do not know the infrastructure on-site we can't really promise how reliable
this will work out.

Looking forward to meeting you all,
Martine

[1] https://dudle.inf.tu-dresden.de/riot-hacknack-regular-dow/
[2] http://en.wikipedia.org/wiki/Central_European_Time
[3] https://www.c-base.org/cv50f/core/impressum.html
[4] http://www.daviko.com/videokonferenz/3-1-Download.html
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Dedicated RIOT Testing Meeting

2014-11-19 Thread Philipp Rosenkranz

Yes, I will provide a link to the minutes soon.

2014-11-19 15:17 GMT+01:00 Martine Lenders :

> Hi,
> Sorry I couldn't attend. Will there be minutes?
>
> Cheers,
> Martine
> Am 19.11.2014 12:58 schrieb "Oleg Hahm" :
>
> Here goes the PlaceCame link:
>> http://placecam.de/call.php?c=VBYEpXi43MZ2MOrV~pegsMm6Z7woUbw.VRY0Qxal2pE-
>>
>> Am Tue, Nov 11, 2014 at 09:13:23PM +0100 schrieb Philipp Rosenkranz:
>> > Hi everyone,
>> >
>> > I'd like to announce that the dedicated RIOT testing meeting will take
>> > place on:
>> >
>> > Wednesday the 19th of November at 01:00 pm CET.
>> >
>> >
>> > We will use PlaceCam for the meeting. If you are using Linux you need to
>> > install
>> > PlaceCam beforehand. PlaceCam can be found at [1].
>> > Please note that you don't need to create an PlaceCam account.
>> > Access to the conference call will be provided by a link which I will
>> share
>> > on this
>> > list shortly before the meeting starts.
>> >
>> > [1] http://www.daviko.com/videokonferenz/3-1-Download.html
>> >
>> >
>> > Best regards,
>> > Philipp
>>
>> > ___
>> > devel mailing list
>> > devel@riot-os.org
>> > http://lists.riot-os.org/mailman/listinfo/devel
>>
>>
>> --
>> /* Ugly, ugly fucker. */
>> linux-2.6.6/include/linux/netfilter_ipv4/ipt_limit.h
>>
>> ___
>> devel mailing list
>> devel@riot-os.org
>> http://lists.riot-os.org/mailman/listinfo/devel
>>
>>
> ___
> devel mailing list
> devel@riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Dedicated RIOT Testing Meeting

2014-11-19 Thread Martine Lenders

Hi,
Sorry I couldn't attend. Will there be minutes?

Cheers,
Martine
Am 19.11.2014 12:58 schrieb "Oleg Hahm" :

> Here goes the PlaceCame link:
> http://placecam.de/call.php?c=VBYEpXi43MZ2MOrV~pegsMm6Z7woUbw.VRY0Qxal2pE-
>
> Am Tue, Nov 11, 2014 at 09:13:23PM +0100 schrieb Philipp Rosenkranz:
> > Hi everyone,
> >
> > I'd like to announce that the dedicated RIOT testing meeting will take
> > place on:
> >
> > Wednesday the 19th of November at 01:00 pm CET.
> >
> >
> > We will use PlaceCam for the meeting. If you are using Linux you need to
> > install
> > PlaceCam beforehand. PlaceCam can be found at [1].
> > Please note that you don't need to create an PlaceCam account.
> > Access to the conference call will be provided by a link which I will
> share
> > on this
> > list shortly before the meeting starts.
> >
> > [1] http://www.daviko.com/videokonferenz/3-1-Download.html
> >
> >
> > Best regards,
> > Philipp
>
> > ___
> > devel mailing list
> > devel@riot-os.org
> > http://lists.riot-os.org/mailman/listinfo/devel
>
>
> --
> /* Ugly, ugly fucker. */
> linux-2.6.6/include/linux/netfilter_ipv4/ipt_limit.h
>
> ___
> devel mailing list
> devel@riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] C++ compiler for stm32f4discovery

2014-11-19 Thread Hiesgen, Raphael

Hi,

we are trying to compile c++ code for the stm32f4discovery. Our implementation 
requires the exception_ptr.h include in the STL exception header, which is only 
defined if the ATOMIC_INT_LOCK_FREE flag is greater than 1. This is not the 
case in the gcc4.8 compiler found on launchpad.

Does anyone know how to circumvent this problem or where we could find an 
alternative compiler?

Thanks
Raphael
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Periodical (virtual) meetings

2014-11-19 Thread Oleg Hahm

Hi!

Here's a draft for the minutes of our meeting this morning:
https://github.com/RIOT-OS/RIOT/wiki/Virtual-Meeting-on-November-19%2C-2014

All participants, please feel free to edit/complement if I missed something.

Cheers,
Oleg
-- 
printk("@#*$  (%08x)\n", ...)
linux-2.6.6/drivers/atm/zatm.c


pgpZmaa6ruPSb.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Dedicated RIOT Testing Meeting

2014-11-19 Thread Oleg Hahm

Here goes the PlaceCame link:
http://placecam.de/call.php?c=VBYEpXi43MZ2MOrV~pegsMm6Z7woUbw.VRY0Qxal2pE-

Am Tue, Nov 11, 2014 at 09:13:23PM +0100 schrieb Philipp Rosenkranz:
> Hi everyone,
> 
> I'd like to announce that the dedicated RIOT testing meeting will take
> place on:
> 
> Wednesday the 19th of November at 01:00 pm CET.
> 
> 
> We will use PlaceCam for the meeting. If you are using Linux you need to
> install
> PlaceCam beforehand. PlaceCam can be found at [1].
> Please note that you don't need to create an PlaceCam account.
> Access to the conference call will be provided by a link which I will share
> on this
> list shortly before the meeting starts.
> 
> [1] http://www.daviko.com/videokonferenz/3-1-Download.html
> 
> 
> Best regards,
> Philipp

> ___
> devel mailing list
> devel@riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel


-- 
/* Ugly, ugly fucker. */
linux-2.6.6/include/linux/netfilter_ipv4/ipt_limit.h


pgpKtD_W3Dbf1.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] FIB redesign

2014-11-19 Thread Martin

Hi again,

I included the FIB to `RIOT/net/sixlowpan/ip` replacing
`ip_get_next_hop()` by the FIB one.

Additionally I edited RPL to feed/update the FIB with the preferred parent.
(I set `23` arbitrary for the protocol ID and 0 for the interface.)

Best regards,
Martin

[1]
https://github.com/BytesGalore/RIOT/blob/add_fib/sys/net/network_layer/fib/fib.c#L354

On 19.11.2014 09:59, Martin wrote:

Hi all,

> a significant question is of course how to deal with competing
routing protocols
Form my understanding we have two distinct directions we can choose to
approach the problem:

1. We strictly push it away from the FIB, i.e. only allowing to have
unique entries for each global prefix.
pro: no handling needed here, the process, e.g. routing protocol,
adding next hops to the FIB must care about this.
con: we loose the possibility to take link/topology/interface
capabilities into account to forward a packet

2. We allow competing entries and apply (sort of) policies to always
return a unambiguous next hop from the FIB.
pro: we are able to direct data and control plane flows, taking
the routing protocol capabilities into account.
con: to have a preference on one FIB entry over another competing
entry, requires a valuing weighting
and decision mechanism. This creates overhead and lowers
the lookup/response time on next hop requests.

> Typically, these routing protocols split horizon according to IP
address ranges
Using a separation on IP address ranges would shift the problem away
from the FIB to the RIB.
This approach is definitely useful on non-moving routers with an
organized and static hierarchy and a good argument for following 1.

But I think in some IoT scenarios with moving routers, this approach
might have a poor performance

when the connected networks between the IoT routers periodically change.

> how does the FIB decide which next hop to choose if more than
routing protocol made an entry pointing to it?
I've built in [1] to the FIB to provide an entry point to handle such
conflicts.

Best Regards,
Martin

[1]
https://github.com/BytesGalore/RIOT/blob/add_fib/sys/net/network_layer/fib/fib.c#L260

On 19.11.2014 00:47, Thomas C. Schmidt wrote:

Hi Martine,

a FIB always only provides unique forwarding rules. So there are no
priorities attached to FIB entries. Priorities of routes may occur in
RIBs associated with routing protocols ... and a significant question
is of course how to deal with competing routing protocols that feed
the FIB. (Typically, these routing protocols split horizon according
to IP address ranges.)

Still, a routing protocol either overrides FIB entries or it doesn't.

Cheers,

Thomas

On 18.11.2014 21:56, Martine Lenders wrote:

Hi,
it's me again, dumping my latest brainstorm into the thread :D.

Don't we need some kind of priorities for the routing protocols,
too? Or

how does the FIB decide which next hop to choose if more than routing
protocol made an entry pointing to it?

Cheers,
Martine

2014-11-17 8:05 GMT+01:00 Martin mailto:martin.landsm...@haw-hamburg.de>>:

Hi Martine,

>... Except you mean the routing protocol by this.
yes, the `prot_id` is the actual used (running) protocol, i.e. RPL.
This identifier must be unique for the running RIOT on the node,
i.e. arbitrary but fixed for the lifetime.

The "binding" of FIB table entries to a specific (running) protocol
is necessary only for updates on them.

Probably `kernel_pid_t` for the would be a waste of one byte for
each FIB table entry.
I will keep it `uint8_t` for now, but test a bit with
`kernel_pid_t`.

Best regards,
Martin

On 15.11.2014 02:03, Martine Lenders wrote:

Hi Martin,

2014-11-14 15:23 GMT+01:00 Martin mailto:martin.landsm...@haw-hamburg.de>>:

Hi Martine,

I will change the interface and protocol IDs to
`kernel_type_t` as you suggested.
For the FIB handling perspective this seems also to be the
best (and easiest) way to have the IDs unique on one
RIOT/node.

For protocol IDs I suggest `netdev_proto_t` [1]. Except you mean
the routing protocol by this. It aims, at least regarding my
design, to be the RIOT-global identifier for all network protocol
RIOT supports.

Cheers,
Martine

[1]
https://github.com/RIOT-OS/RIOT/blob/038beb0f99215207c09fd862ac7712982cedb3ef/drivers/include/netdev/base.h#L57

___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Periodical (virtual) meetings

2014-11-19 Thread Oleg Hahm

Hi Ludwig!

> the download link does not work for me.

With Arch you'll have to download
http://www.daviko.com/software/PlaceCam_v4.2.2.tar.gz (link seems to be
working) and then exec PlaceCam with the URL as a parameter.

Cheers,
Oleg
-- 
/*
 * Hash table gook..
 */
linux-2.4.0-test2/fs/buffer.c


pgpzpPUj9pSk5.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Periodical (virtual) meetings

2014-11-19 Thread Ludwig Ortmann

Hi,

the download link does not work for me.

Cheers, Ludwig

On Wed, Nov 19, 2014 at 09:58:42AM +0100, Oleg Hahm wrote:
> And here comes the PlaceCam-Link:
> http://placecam.de/call.php?c=VBYEpXi43MZ2MOrV~pegsMm6Z7woUbw.VRY0Qxal2pE-
> 
> Am Tue, Nov 18, 2014 at 01:40:52PM +0100 schrieb Oleg Hahm:
> > Dear RIOTers!
> > 
> > > Here's the poll:
> > > https://dudle.inf.tu-dresden.de/RIOT-virt-dev-regular/
> > 
> > According to this poll, everyone is fine with having the meeting on 
> > Wednesday
> > morning. So, in case no one objects, I would suggest to schedule it every
> > first and third Wednesday of the month at 10am CET.
> > 
> > Hence, our next meeting will take place tomorrow morning. PlaceCam link will
> > be sent around in advance.
> > 
> > Cheers,
> > Oleg
> > -- 
> > printk ("Barf\n");
> > linux-2.6.6/arch/v850/kernel/module.c
> 
> 
> 
> > ___
> > devel mailing list
> > devel@riot-os.org
> > http://lists.riot-os.org/mailman/listinfo/devel
> 
> 
> -- 
> dprintk("kick_rx: maybe kicking\n");
> linux-2.6.6/drivers/net/ns83820.c



> ___
> devel mailing list
> devel@riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel

___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] FIB redesign

2014-11-19 Thread Martin

Hi all,

> a significant question is of course how to deal with competing
routing protocols
Form my understanding we have two distinct directions we can choose to
approach the problem:

2. We allow competing entries and apply (sort of) policies to always
return a unambiguous next hop from the FIB.
pro: we are able to direct data and control plane flows, taking the
routing protocol capabilities into account.
con: to have a preference on one FIB entry over another competing
entry, requires a valuing weighting
and decision mechanism. This creates overhead and lowers
the lookup/response time on next hop requests.

But I think in some IoT scenarios with moving routers, this approach
might have a poor performance

when the connected networks between the IoT routers periodically change.

> how does the FIB decide which next hop to choose if more than routing
protocol made an entry pointing to it?
I've built in [1] to the FIB to provide an entry point to handle such
conflicts.

Best Regards,
Martin

[1]
https://github.com/BytesGalore/RIOT/blob/add_fib/sys/net/network_layer/fib/fib.c#L260

On 19.11.2014 00:47, Thomas C. Schmidt wrote:

Hi Martine,

Still, a routing protocol either overrides FIB entries or it doesn't.

Cheers,

Thomas

On 18.11.2014 21:56, Martine Lenders wrote:

Hi,
it's me again, dumping my latest brainstorm into the thread :D.

Don't we need some kind of priorities for the routing protocols, too? Or
how does the FIB decide which next hop to choose if more than routing
protocol made an entry pointing to it?

Cheers,
Martine

2014-11-17 8:05 GMT+01:00 Martin mailto:martin.landsm...@haw-hamburg.de>>:

Hi Martine,

The "binding" of FIB table entries to a specific (running) protocol
is necessary only for updates on them.

Probably `kernel_pid_t` for the would be a waste of one byte for
each FIB table entry.
I will keep it `uint8_t` for now, but test a bit with
`kernel_pid_t`.

Best regards,
Martin

On 15.11.2014 02:03, Martine Lenders wrote:

Hi Martin,

2014-11-14 15:23 GMT+01:00 Martin mailto:martin.landsm...@haw-hamburg.de>>:

Hi Martine,

Cheers,
Martine

[1]
https://github.com/RIOT-OS/RIOT/blob/038beb0f99215207c09fd862ac7712982cedb3ef/drivers/include/netdev/base.h#L57

___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Periodical (virtual) meetings

2014-11-19 Thread Oleg Hahm

And here comes the PlaceCam-Link:
http://placecam.de/call.php?c=VBYEpXi43MZ2MOrV~pegsMm6Z7woUbw.VRY0Qxal2pE-

Am Tue, Nov 18, 2014 at 01:40:52PM +0100 schrieb Oleg Hahm:
> Dear RIOTers!
> 
> > Here's the poll:
> > https://dudle.inf.tu-dresden.de/RIOT-virt-dev-regular/
> 
> According to this poll, everyone is fine with having the meeting on Wednesday
> morning. So, in case no one objects, I would suggest to schedule it every
> first and third Wednesday of the month at 10am CET.
> 
> Hence, our next meeting will take place tomorrow morning. PlaceCam link will
> be sent around in advance.
> 
> Cheers,
> Oleg
> -- 
> printk ("Barf\n");
> linux-2.6.6/arch/v850/kernel/module.c



> ___
> devel mailing list
> devel@riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel


-- 
dprintk("kick_rx: maybe kicking\n");
linux-2.6.6/drivers/net/ns83820.c


pgphZX8e9VkhX.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] vtimer in native port

[riot-devel] vtimer in native port

Re: [riot-devel] Dedicated RIOT Testing Meeting

[riot-devel] Hack'n'ACK - Part V - The Pull Requests Strike Back

Re: [riot-devel] Dedicated RIOT Testing Meeting

Re: [riot-devel] Dedicated RIOT Testing Meeting

[riot-devel] C++ compiler for stm32f4discovery

Re: [riot-devel] Periodical (virtual) meetings

Re: [riot-devel] Dedicated RIOT Testing Meeting

Re: [riot-devel] FIB redesign

Re: [riot-devel] Periodical (virtual) meetings

Re: [riot-devel] Periodical (virtual) meetings

Re: [riot-devel] FIB redesign

Re: [riot-devel] Periodical (virtual) meetings

14 matches

Site Navigation

Mail list logo

Footer information