From Woeber at CC.UniVie.ac.at Fri Apr 8 21:23:28 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 08 Apr 2011 19:23:28 +0000 Subject: [atlas]time base / synch for the "lst two hours" graphs? In-Reply-To: <4D939181.7080203@ripe.net> References: <4D9338FF.2090804@CC.UniVie.ac.at> <4D9345FC.7070608@ripe.net> <4D935374.5030906@CC.UniVie.ac.at> <4D939181.7080203@ripe.net> Message-ID: <4D9F60B0.9090902@CC.UniVie.ac.at> Viktor, fist of all thanks for the explanation of the control parameters! Being able to configure the plots is extremely helpful. There's one thing that I would like to do, if possible with your interface: I'd like to control the scaling of the Y-axis, in order to make graphs "optically comparable" on the spot. Is this possible? TIA Wilfried. Viktor Naoumov wrote: > On 03/30/2011 05:59 PM, Wilfried Woeber, UniVie/ACOnet wrote: > >> Hi Viktor, >> >> thanks for the explanation! > > you're welcome > >> OK, thanks for this. Is there a description somewhere? >> prb_id is obvious :-) but which valuess are valid for msm_id? >> I presume I can guess the values for type... >> > Here you go... > > msm_id you can find out in the web page source :) > > http:/atlas.ripe.net/atlas/rrd.png?prb_id=1&msm_id=2&type=daily&end=last > > .png - file type (can be .png, .svg, .eps, .pdf) > > List and description of GET arguments: > > prb_id - Probe ID > msm_id - Measurement ID > graph - graph name. Predefined collection of graphs currently 'tiny_rtt' > and 'default'. If not defined - 'default' is assumed > type - type of the graphs: > 'minutely' : 'end-7200' - 'now' > 'hourly' : 'end-28800' - 'now' > 'daily' : 'end-90000' - 'now' > 'weekly' : 'end-691200' - 'now' > 'monthly' : 'end-2678400' - 'now' > 'yearly' : 'end-31536000' - 'now' > > start - when graph should begin (see AT-STYLE TIME SPECIFICATION on RRD > fetch page) > end - when graph should end, same as start but also included keyword > 'last', that end the graph at the last entered measurement > 'start' and 'end' override 'type' > width - width of the graph canvas in pixels (Title, legend, axis names > are not included) > height - canvas height in pixels (Title, legend, axis names are not > included) > > Best regards, > > /vty > From Woeber at CC.UniVie.ac.at Fri Apr 8 21:32:57 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 08 Apr 2011 19:32:57 +0000 Subject: [atlas]Feature request (fo consideration): broadcast rate measurement? Message-ID: <4D9F62E9.2030109@CC.UniVie.ac.at> Xmas WishList 2011 :-) Looking at the yellow LED of the probes, I presume that their Ethernet IF operates in promiscuous mode. Even if not... I'd like to see some (easily configurable) measurement available, at least the rate of broadcast-packets on the probe's net. On a more elaborate basis, maybe according to simple paramters like a protocol/port combination. Would this make sense to implement and be of interest to others? Thanks for consideration, Wilfried. PS: yes, I do know about Netflow, WireShark and similar, but the beauty of the ATLAS Probe Approach is imho in the ready-nade UI :-) From vnaumov at ripe.net Fri Apr 8 22:18:38 2011 From: vnaumov at ripe.net (Viktor Naoumov) Date: Fri, 08 Apr 2011 22:18:38 +0200 Subject: [atlas]time base / synch for the "lst two hours" graphs? In-Reply-To: <4D9F60B0.9090902@CC.UniVie.ac.at> References: <4D9338FF.2090804@CC.UniVie.ac.at> <4D9345FC.7070608@ripe.net> <4D935374.5030906@CC.UniVie.ac.at> <4D939181.7080203@ripe.net> <4D9F60B0.9090902@CC.UniVie.ac.at> Message-ID: <4D9F6D9E.6010400@ripe.net> Hi Wilfried, It's not possible at the moment. See Robert's email about access to your data, so you can build graph yourself. WBR /vty On 04/08/2011 09:23 PM, Wilfried Woeber, UniVie/ACOnet wrote: > Viktor, > > fist of all thanks for the explanation of the control parameters! > Being able to configure the plots is extremely helpful. > > There's one thing that I would like to do, if possible with your > interface: I'd like to control the scaling of the Y-axis, in order > to make graphs "optically comparable" on the spot. Is this possible? > > TIA > Wilfried. > > Viktor Naoumov wrote: >> On 03/30/2011 05:59 PM, Wilfried Woeber, UniVie/ACOnet wrote: >> >>> Hi Viktor, >>> >>> thanks for the explanation! >> you're welcome >> >>> OK, thanks for this. Is there a description somewhere? >>> prb_id is obvious :-) but which valuess are valid for msm_id? >>> I presume I can guess the values for type... >>> >> Here you go... >> >> msm_id you can find out in the web page source :) >> >> http:/atlas.ripe.net/atlas/rrd.png?prb_id=1&msm_id=2&type=daily&end=last >> >> .png - file type (can be .png, .svg, .eps, .pdf) >> >> List and description of GET arguments: >> >> prb_id - Probe ID >> msm_id - Measurement ID >> graph - graph name. Predefined collection of graphs currently 'tiny_rtt' >> and 'default'. If not defined - 'default' is assumed >> type - type of the graphs: >> 'minutely' : 'end-7200' - 'now' >> 'hourly' : 'end-28800' - 'now' >> 'daily' : 'end-90000' - 'now' >> 'weekly' : 'end-691200' - 'now' >> 'monthly' : 'end-2678400' - 'now' >> 'yearly' : 'end-31536000' - 'now' >> >> start - when graph should begin (see AT-STYLE TIME SPECIFICATION on RRD >> fetch page) >> end - when graph should end, same as start but also included keyword >> 'last', that end the graph at the last entered measurement >> 'start' and 'end' override 'type' >> width - width of the graph canvas in pixels (Title, legend, axis names >> are not included) >> height - canvas height in pixels (Title, legend, axis names are not >> included) >> >> Best regards, >> >> /vty >> From jesper at skriver.dk Sat Apr 9 11:42:50 2011 From: jesper at skriver.dk (Jesper Skriver) Date: Sat, 09 Apr 2011 12:42:50 +0300 Subject: [atlas]Feature request (fo consideration): broadcast rate measurement? Message-ID: <34kld70u23xnorakkkiwngtq.1302342170652@email.android.com> Hi As I see it the atlas project is about getting a global view. So in my book the last thing we want is stats about the local LAN segment the probe is connected to. Further more for privacy and security reasons the probes should in my mind gather as little information about the directly attached network as possible. /Jesper "Wilfried Woeber, UniVie/ACOnet" wrote: >Xmas WishList 2011 :-) > >Looking at the yellow LED of the probes, I presume that their Ethernet IF >operates in promiscuous mode. Even if not... > >I'd like to see some (easily configurable) measurement available, at least >the rate of broadcast-packets on the probe's net. > >On a more elaborate basis, maybe according to simple paramters like a >protocol/port combination. > >Would this make sense to implement and be of interest to others? > >Thanks for consideration, >Wilfried. > >PS: yes, I do know about Netflow, WireShark and similar, but the beauty of > the ATLAS Probe Approach is imho in the ready-nade UI :-) > From florian at narrans.de Sun Apr 10 11:55:05 2011 From: florian at narrans.de (Florian Obser) Date: Sun, 10 Apr 2011 11:55:05 +0200 Subject: [atlas]strange dns resolver display Message-ID: <4DA17E79.5030205@narrans.de> Hi, Probe ID: 167 Firmware Version: 4020 DNS Resolver: ,1,9,2,.,1,6,8,.,1,0,0,.,2,5,4 (it should be 192.168.100.254) For what it's worth I had a lot of problems with my dsl connection since April 1st, switching to umts and back to dsl, rebooting the router a lot while the probe was constantly powered up. Thanks, Florian -- I remember yesterday, but the memory is in my head now. Was yesterday real? Or is it only the memory that is real? From daniel.karrenberg at ripe.net Mon Apr 11 08:50:09 2011 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 11 Apr 2011 08:50:09 +0200 Subject: [atlas]Feature request (fo consideration): broadcast rate measurement? In-Reply-To: <34kld70u23xnorakkkiwngtq.1302342170652@email.android.com> References: <34kld70u23xnorakkkiwngtq.1302342170652@email.android.com> Message-ID: <20110411065009.GA45554@reifripenet.local> On 09.04 12:42, Jesper Skriver wrote: > Hi > > As I see it the atlas project is about getting a global view. So in my book the last thing we want is stats about the local LAN segment the probe is connected to. Further more for privacy and security reasons the probes should in my mind gather as little information about the directly attached network as possible. > > /Jesper I agree. Whhile this may be interesting it is the first step on a slippery slope towards passive measurements which would endagner confidence in the "we are not listening to your traffic" message. Daniel From Woeber at CC.UniVie.ac.at Mon Apr 11 12:29:49 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Mon, 11 Apr 2011 10:29:49 +0000 Subject: [atlas]Feature request (fo consideration): broadcast rate measurement? In-Reply-To: <20110411065009.GA45554@reifripenet.local> References: <34kld70u23xnorakkkiwngtq.1302342170652@email.android.com> <20110411065009.GA45554@reifripenet.local> Message-ID: <4DA2D81D.301@CC.UniVie.ac.at> Good points, thanks! Wilfried Daniel Karrenberg wrote: > On 09.04 12:42, Jesper Skriver wrote: > >>Hi >> >>As I see it the atlas project is about getting a global view. So in my book the last thing we want is stats about the local LAN segment the probe is connected to. Further more for privacy and security reasons the probes should in my mind gather as little information about the directly attached network as possible. >> >>/Jesper > > > I agree. Whhile this may be interesting it is the first step > on a slippery slope towards passive measurements which would > endagner confidence in the "we are not listening to your traffic" > message. > > Daniel >