From Woeber at CC.UniVie.ac.at Wed Mar 2 13:08:04 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 02 Mar 2011 12:08:04 +0000 Subject: [atlas] Suggestion for data display [was: Atlas website upgrades] In-Reply-To: <475C75FC-1FA8-4AB6-B7A2-5E4B838879DA@ripe.net> References: <475C75FC-1FA8-4AB6-B7A2-5E4B838879DA@ripe.net> Message-ID: <4D6E3324.9090702@CC.UniVie.ac.at> Dear Atlas Team! Andreas Strikos wrote: [...] > Except from the template, there are some other changes in UI like a > new tab for public probes and a bigger settings button. [...] I'd like to "request" a small(?) addition to the info display on the probe-list tabs - in particular for the public ones: Could you please include an indication in the "status" column about the IPv6-capabilities of a probe? Eg instead of just "up", I'd like to see "up4, up6" or just "up4" or "up4, down6". In the future we may even have a status of "up6" only :-) Thanks for your consideration, Wilfried From rm at romanrm.ru Wed Mar 2 13:30:59 2011 From: rm at romanrm.ru (Roman Mamedov) Date: Wed, 2 Mar 2011 17:30:59 +0500 Subject: [atlas] Suggestion for data display [was: Atlas website upgrades] In-Reply-To: <4D6E3324.9090702@CC.UniVie.ac.at> References: <475C75FC-1FA8-4AB6-B7A2-5E4B838879DA@ripe.net> <4D6E3324.9090702@CC.UniVie.ac.at> Message-ID: <20110302173059.20935946@natsu> On Wed, 02 Mar 2011 12:08:04 +0000 "Wilfried Woeber, UniVie/ACOnet" wrote: > I'd like to "request" a small(?) addition to the info display on the > probe-list tabs - in particular for the public ones: > > Could you please include an indication in the "status" column about the > IPv6-capabilities of a probe? > > Eg instead of just "up", I'd like to see "up4, up6" or just "up4" or > "up4, down6". In the future we may even have a status of "up6" only :-) A related note: can we please also have a separate display of IPv4 AS and IPv6 AS in node details on the map at http://atlas.ripe.net/ ? IPv4 AS and IPv6 AS numbers are different for all users of IPv6 tunnels. -- With respect, Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From robert at ripe.net Wed Mar 2 14:37:38 2011 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 02 Mar 2011 14:37:38 +0100 Subject: [atlas] Suggestion for data display [was: Atlas website upgrades] In-Reply-To: <20110302173059.20935946@natsu> References: <475C75FC-1FA8-4AB6-B7A2-5E4B838879DA@ripe.net> <4D6E3324.9090702@CC.UniVie.ac.at> <20110302173059.20935946@natsu> Message-ID: <4D6E4822.8030106@ripe.net> On 2011.03.02. 13:30, Roman Mamedov wrote: > On Wed, 02 Mar 2011 12:08:04 +0000 > "Wilfried Woeber, UniVie/ACOnet" wrote: > >> I'd like to "request" a small(?) addition to the info display on the >> probe-list tabs - in particular for the public ones: >> >> Could you please include an indication in the "status" column about the >> IPv6-capabilities of a probe? >> >> Eg instead of just "up", I'd like to see "up4, up6" or just "up4" or >> "up4, down6". In the future we may even have a status of "up6" only :-) > > A related note: can we please also have a separate display of IPv4 AS and IPv6 > AS in node details on the map at http://atlas.ripe.net/ ? > IPv4 AS and IPv6 AS numbers are different for all users of IPv6 tunnels. Thank you for these; I think both are good suggestions. We're working on a method to discover both addresses of the probes, then we can implement these features. Watch this space! :-) Regards, Robert From Woeber at CC.UniVie.ac.at Fri Mar 4 14:26:30 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 04 Mar 2011 13:26:30 +0000 Subject: [atlas]too many disconnects? Message-ID: <4D70E886.1060002@CC.UniVie.ac.at> [my apologies to the Team for the duplicate, I 1st picked the wrong address] Q to the Team and to the Probe Hosts: My feeling is that the probes do register too many "disconnects". I just had a look at the two under my control and the numbers of transitions are - 466: 25 events between 2010-12-21 07:14:30 UTC and 2011-03-01 10:24:11 UTC 414: 25 events between 2010-11-22 12:31:02 UTC and 2011-02-20 20:18:24 UTC While there may be a local reason for some of the down-periods, I doubt that I had so many outages on my ends. Is anyone else seeing a similar pattern? Regarding presentation, again, could we please have an additional item of "Total Downtime" (next to the "Total Uptime"), and the duration of the downs in the 25 lines with the time stamps? This would make it much more straight- forward to spot patterns.... Minor cosmetics, relevant when reporting stuff, could the probe's number be displayed somewhere in the Probe Conf panel (e.g. in the line with the Firmware Version)? Thanks for your consideration, have a nice weekend Wilfried From robert at ripe.net Fri Mar 4 15:29:22 2011 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 04 Mar 2011 15:29:22 +0100 Subject: [atlas]too many disconnects? In-Reply-To: <4D70E886.1060002@CC.UniVie.ac.at> References: <4D70E886.1060002@CC.UniVie.ac.at> Message-ID: <4D70F742.8060704@ripe.net> Hi, On 2011.03.04. 14:26, Wilfried Woeber, UniVie/ACOnet wrote: > [my apologies to the Team for the duplicate, I 1st picked the wrong address] > > > Q to the Team and to the Probe Hosts: > > > My feeling is that the probes do register too many "disconnects". > I just had a look at the two under my control and the numbers of transitions > are - > > 466: 25 events between 2010-12-21 07:14:30 UTC and 2011-03-01 10:24:11 UTC > 414: 25 events between 2010-11-22 12:31:02 UTC and 2011-02-20 20:18:24 UTC > > While there may be a local reason for some of the down-periods, I doubt > that I had so many outages on my ends. Is anyone else seeing a similar > pattern? Disconnects and reconnects are expected; the probes are somewhat sensitive in this regard. Most of these downtimes should be less than 5, at most 10 minutes. This is normal, don't worry about them. > Regarding presentation, again, could we please have an additional item of > "Total Downtime" (next to the "Total Uptime"), and the duration of the downs > in the 25 lines with the time stamps? This would make it much more straight- > forward to spot patterns.... Yes, this is in fact already working in our test environment! ETA for public rollout is next week. > Minor cosmetics, relevant when reporting stuff, could the probe's number > be displayed somewhere in the Probe Conf panel (e.g. in the line with the > Firmware Version)? Sure. Cheers, Robert > Thanks for your consideration, > have a nice weekend > Wilfried From antony at ripe.net Mon Mar 7 14:31:47 2011 From: antony at ripe.net (Antony Antony) Date: Mon, 7 Mar 2011 14:31:47 +0100 Subject: [atlas]too many disconnects? In-Reply-To: <4D70F742.8060704@ripe.net> References: <4D70E886.1060002@CC.UniVie.ac.at> <4D70F742.8060704@ripe.net> Message-ID: <20110307133147.GA19277@dog.ripe.net> Hi Wilfried, some more details. Each probe have two tasks: measure and keep connection to the controllers. These tasks are some what independent, and the idea is to make the probe more autonomous. The connection to the controller controls the probe and exchange results. It is a TCP session. The experience shows a session stay up from several minutes to about a month. I think the longest we have seen so far is 5 weeks. My guess is on average it is several hours to days. Even when the session drops the measurements continues. The results will be overwritten after a while. However, when a connection is established the probe will send the old results. After a connection reset the probe will try to reconnect. From a experience typical reconnect time are between 1-10 minutes. So, in short disconnects are not bad if probe reconnect again immediately. For example there some probes, in DSL networks in Germany, reconnects daily, when the modem get a different IP address. These re-connects are like a clockwork. Also, I hope, with experience we can tune the tcp keep-alive and timeout parameters to make the sessions more resilient intermittent changes. One more detail if the probe run out resources, such as contiguous RAM (memory fragmentation), it will reboot itself. Reboot is quick, takes some seconds. regards, -antony On Fri, Mar 04, 2011 at 03:29:22PM +0100, Robert Kisteleki wrote: > Hi, > > On 2011.03.04. 14:26, Wilfried Woeber, UniVie/ACOnet wrote: > > [my apologies to the Team for the duplicate, I 1st picked the wrong address] > > > > > > Q to the Team and to the Probe Hosts: > > > > > > My feeling is that the probes do register too many "disconnects". > > I just had a look at the two under my control and the numbers of transitions > > are - > > > > 466: 25 events between 2010-12-21 07:14:30 UTC and 2011-03-01 10:24:11 UTC > > 414: 25 events between 2010-11-22 12:31:02 UTC and 2011-02-20 20:18:24 UTC > > > > While there may be a local reason for some of the down-periods, I doubt > > that I had so many outages on my ends. Is anyone else seeing a similar > > pattern? > > Disconnects and reconnects are expected; the probes are somewhat sensitive > in this regard. Most of these downtimes should be less than 5, at most 10 > minutes. This is normal, don't worry about them. > > > Regarding presentation, again, could we please have an additional item of > > "Total Downtime" (next to the "Total Uptime"), and the duration of the downs > > in the 25 lines with the time stamps? This would make it much more straight- > > forward to spot patterns.... > > Yes, this is in fact already working in our test environment! ETA for public > rollout is next week. > > > Minor cosmetics, relevant when reporting stuff, could the probe's number > > be displayed somewhere in the Probe Conf panel (e.g. in the line with the > > Firmware Version)? > > Sure. > > Cheers, > Robert > > > Thanks for your consideration, > > have a nice weekend > > Wilfried > > From astrikos at ripe.net Mon Mar 7 16:48:51 2011 From: astrikos at ripe.net (Andreas Strikos) Date: Mon, 7 Mar 2011 16:48:51 +0100 Subject: [atlas]New Atlas Features Message-ID: Dear Hosts, We've now enabled two features that were requested by hosts earlier: 1. The "Probe DNS" function allows you to ask for a DNS entry for you probe. Operational details: * The exact DNS name of your probe depends on your settings (simple or obfuscated), and can be looked up on the "Probe Conf" section of the probe status page. * The zone file is re-generated every 15 minutes. * The resulting address is the one we observe when the probe to connects to our infrastructure, so if you're using NAT then it's the public address of the NAT device. Currently it's either IPv4 or IPv6, but not both. We'll add the "other address" too in the future. 2. The probe uptime section has more details. It now contains: * Relative uptime for the last week and month, and for the full lifetime. * The source IP address of the individual connections. * The amount of up- and downtime (in days/hours/minutes), for each connection. Regards, Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From Woeber at CC.UniVie.ac.at Mon Mar 7 17:19:37 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Mon, 07 Mar 2011 16:19:37 +0000 Subject: [atlas]New Atlas Features In-Reply-To: References: Message-ID: <4D750599.4070608@CC.UniVie.ac.at> Hi Andreas, Team! Andreas Strikos wrote: > Dear Hosts, [...] > 2. The probe uptime section has more details. It now contains: > * Relative uptime for the last week and month, and for the full lifetime. > * The source IP address of the individual connections. > * The amount of up- and downtime (in days/hours/minutes), for each > connection. Great stuff! Is there a "cheap" way to upgrade the blue bar ("UPTIME") to plot data availability against uptime of the control connection? > Regards, > Andreas For the time being until resolved, I am looking for some machanism to detect at first glance that the delivery of measurement data is not functioning. I also noticed a change in panel labelling: Built-in Measurements :-) Thanks, Wilfried. From rbarnes at bbn.com Thu Mar 24 15:51:10 2011 From: rbarnes at bbn.com (Richard L. Barnes) Date: Thu, 24 Mar 2011 10:51:10 -0400 Subject: [atlas]Simple way to open API access? Message-ID: <8547D376-0BDC-4AC4-A51A-78DE5C97EF13@bbn.com> Hey all, Suggestion for a simple way to provide some basic automated access to ATLAS data: It's pretty clear from the traffic that the site is driven off a set of JSON APIs [1]. This would make it pretty easy to write scripts that can access information from the site -- except that the script would need to have a Cookie for a valid user session. So it seems like a simple way to open access up would be to allow developers to access these JSON APIs, but with a different form of authentication. Namely, you could grant developers an "API key" that would function in the same way as a 'stat-session' cookie (in particular it would be bound to a developer identity/email), but would last indefinitely. This wouldn't really put any burden on the NCC other than to have a page to register the API keys. It would be helpful to document the APIs, but not strictly necessary, since JSON is so verbose. And you wouldn't necessarily have any additional requirements for the APIs to be stable, if this feature were properly marked as experimental/undocumented. Noting that the other cookie that the ATLAS page sets is "csrftoken" (which would probably have to be ignored in API key requests), it is worth noting that there is some risk with this approach that a bad developer will use this mechanism to enable CSRF attacks. But such attacks should be fairly easy to recognize, and if one is, then the relevant developer can be turned off. Just a thought, --Richard [1] For example From robert at ripe.net Thu Mar 24 16:08:48 2011 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 24 Mar 2011 16:08:48 +0100 Subject: [atlas]Simple way to open API access? In-Reply-To: <8547D376-0BDC-4AC4-A51A-78DE5C97EF13@bbn.com> References: <8547D376-0BDC-4AC4-A51A-78DE5C97EF13@bbn.com> Message-ID: <4D8B5E80.8040307@ripe.net> Hi, Virtually all client libraries know how to handl cookies. I believe that nothing is stopping you from authenticating your API client's session with your usual name/password using the login URL, and then use the authenticated cookie to fetch the data. Of course it's a two step process, but it's easily automated and has much better security properties. Robert On 2011.03.24. 15:51, Richard L. Barnes wrote: > Hey all, > > Suggestion for a simple way to provide some basic automated access to ATLAS data: > > It's pretty clear from the traffic that the site is driven off a set of JSON APIs [1]. This would make it pretty easy to write scripts that can access information from the site -- except that the script would need to have a Cookie for a valid user session. > > So it seems like a simple way to open access up would be to allow developers to access these JSON APIs, but with a different form of authentication. Namely, you could grant developers an "API key" that would function in the same way as a 'stat-session' cookie (in particular it would be bound to a developer identity/email), but would last indefinitely. > > This wouldn't really put any burden on the NCC other than to have a page to register the API keys. It would be helpful to document the APIs, but not strictly necessary, since JSON is so verbose. And you wouldn't necessarily have any additional requirements for the APIs to be stable, if this feature were properly marked as experimental/undocumented. > > Noting that the other cookie that the ATLAS page sets is "csrftoken" (which would probably have to be ignored in API key requests), it is worth noting that there is some risk with this approach that a bad developer will use this mechanism to enable CSRF attacks. But such attacks should be fairly easy to recognize, and if one is, then the relevant developer can be turned off. > > Just a thought, > --Richard > > > [1] For example From rbarnes at bbn.com Thu Mar 24 16:18:07 2011 From: rbarnes at bbn.com (Richard L. Barnes) Date: Thu, 24 Mar 2011 11:18:07 -0400 Subject: [atlas]Simple way to open API access? In-Reply-To: <4D8B5E80.8040307@ripe.net> References: <8547D376-0BDC-4AC4-A51A-78DE5C97EF13@bbn.com> <4D8B5E80.8040307@ripe.net> Message-ID: <0C9E3584-8DCB-4A67-BF05-DD76F85AB308@bbn.com> That's true, but it has the irritation that the session cookies expire, in 24 hours IIRC. So if you want to run a script every few days, you have to manually reconfigure it -- or spoof the login page! --Richard On Mar 24, 2011, at 11:08 AM, Robert Kisteleki wrote: > Hi, > > Virtually all client libraries know how to handl cookies. I believe that > nothing is stopping you from authenticating your API client's session with > your usual name/password using the login URL, and then use the authenticated > cookie to fetch the data. Of course it's a two step process, but it's easily > automated and has much better security properties. > > Robert > > > On 2011.03.24. 15:51, Richard L. Barnes wrote: >> Hey all, >> >> Suggestion for a simple way to provide some basic automated access to ATLAS data: >> >> It's pretty clear from the traffic that the site is driven off a set of JSON APIs [1]. This would make it pretty easy to write scripts that can access information from the site -- except that the script would need to have a Cookie for a valid user session. >> >> So it seems like a simple way to open access up would be to allow developers to access these JSON APIs, but with a different form of authentication. Namely, you could grant developers an "API key" that would function in the same way as a 'stat-session' cookie (in particular it would be bound to a developer identity/email), but would last indefinitely. >> >> This wouldn't really put any burden on the NCC other than to have a page to register the API keys. It would be helpful to document the APIs, but not strictly necessary, since JSON is so verbose. And you wouldn't necessarily have any additional requirements for the APIs to be stable, if this feature were properly marked as experimental/undocumented. >> >> Noting that the other cookie that the ATLAS page sets is "csrftoken" (which would probably have to be ignored in API key requests), it is worth noting that there is some risk with this approach that a bad developer will use this mechanism to enable CSRF attacks. But such attacks should be fairly easy to recognize, and if one is, then the relevant developer can be turned off. >> >> Just a thought, >> --Richard >> >> >> [1] For example > From vnaumov at ripe.net Thu Mar 24 18:19:04 2011 From: vnaumov at ripe.net (Viktor Naoumov) Date: Thu, 24 Mar 2011 18:19:04 +0100 Subject: [atlas]Simple way to open API access? In-Reply-To: <0C9E3584-8DCB-4A67-BF05-DD76F85AB308@bbn.com> References: <8547D376-0BDC-4AC4-A51A-78DE5C97EF13@bbn.com> <4D8B5E80.8040307@ripe.net> <0C9E3584-8DCB-4A67-BF05-DD76F85AB308@bbn.com> Message-ID: <4D8B7D08.7030300@ripe.net> Hi Richard, Thats pretty simple :) --------------------------------------------- import mechanize br = mechanize.Browser() br.open("https://atlas.ripe.net/atlas/login/") br.select_form(nr=1) br['username'] = 'rbarnes at bbn.com' br['password'] = '' br.submit() print br.open("https://atlas.ripe.net/atlas/publicprobesgrid.json").read() ---------------------------------------------- Regards /vty On 03/24/2011 04:18 PM, Richard L. Barnes wrote: > That's true, but it has the irritation that the session cookies expire, in 24 hours IIRC. So if you want to run a script every few days, you have to manually reconfigure it -- or spoof the login page! > > --Richard > > > > On Mar 24, 2011, at 11:08 AM, Robert Kisteleki wrote: > >> Hi, >> >> Virtually all client libraries know how to handl cookies. I believe that >> nothing is stopping you from authenticating your API client's session with >> your usual name/password using the login URL, and then use the authenticated >> cookie to fetch the data. Of course it's a two step process, but it's easily >> automated and has much better security properties. >> >> Robert >> >> >> On 2011.03.24. 15:51, Richard L. Barnes wrote: >>> Hey all, >>> >>> Suggestion for a simple way to provide some basic automated access to ATLAS data: >>> >>> It's pretty clear from the traffic that the site is driven off a set of JSON APIs [1]. This would make it pretty easy to write scripts that can access information from the site -- except that the script would need to have a Cookie for a valid user session. >>> >>> So it seems like a simple way to open access up would be to allow developers to access these JSON APIs, but with a different form of authentication. Namely, you could grant developers an "API key" that would function in the same way as a 'stat-session' cookie (in particular it would be bound to a developer identity/email), but would last indefinitely. >>> >>> This wouldn't really put any burden on the NCC other than to have a page to register the API keys. It would be helpful to document the APIs, but not strictly necessary, since JSON is so verbose. And you wouldn't necessarily have any additional requirements for the APIs to be stable, if this feature were properly marked as experimental/undocumented. >>> >>> Noting that the other cookie that the ATLAS page sets is "csrftoken" (which would probably have to be ignored in API key requests), it is worth noting that there is some risk with this approach that a bad developer will use this mechanism to enable CSRF attacks. But such attacks should be fairly easy to recognize, and if one is, then the relevant developer can be turned off. >>> >>> Just a thought, >>> --Richard >>> >>> >>> [1] For example From robert at ripe.net Tue Mar 29 13:46:50 2011 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 29 Mar 2011 13:46:50 +0200 Subject: [atlas]Statically configures probes - call for testers Message-ID: <4D91C6AA.3010901@ripe.net> Hi, In a few days we'll be ready with a firmware that will support statically configured (IPv4) addresses for the probes. We'd like to test this out and get feedback from the interested people before we release it fully. So, if you are running a probe and would like to test the new functionality, please drop me a line. Cheers, Robert From Woeber at CC.UniVie.ac.at Wed Mar 30 15:52:45 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 30 Mar 2011 13:52:45 +0000 Subject: [atlas]"perceived" downtime of probe? Message-ID: <4D9335AD.8000500@CC.UniVie.ac.at> Hi Team, could you please have a look at the data for my 414, the "uptime" info claims a downtime of 7d, 16h, 51m, disconnected at 2011-03-22 20:50:26 UTC, up again at 2011-03-30 13:41:40 UTC. (the reason for the very short(!) interruption *today* was the need to move the USB cable to a different outlet...) [1] At the same time there is *no* loss of measurement data for this period!? Has anyone else seen such a situation recently? Wilfried [1] it would really be "cool" to ship future probes with some sort of "Y"-cable which w|should allow moving probes without loss of power, and/or to connect one plug to a UPS-fed outlet :-) From Woeber at CC.UniVie.ac.at Wed Mar 30 16:06:55 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 30 Mar 2011 14:06:55 +0000 Subject: [atlas]time base / synch for the "lst two hours" graphs? Message-ID: <4D9338FF.2090804@CC.UniVie.ac.at> I just noticed that the various graphs for the "last 2 hours" display seem to be based on different clocks or update cycles (delta = some 25m). Should these graphs be "synchronised"? >From a UI-perspective it would certainly be a bonus to have them aligned, at least for one probe. All the best, Wilfried. From astrikos at ripe.net Wed Mar 30 16:36:13 2011 From: astrikos at ripe.net (Andreas Strikos) Date: Wed, 30 Mar 2011 16:36:13 +0200 Subject: Fwd: [atlas]"perceived" downtime of probe? References: Message-ID: <6268E719-92E7-434E-A233-BF542AFBCB16@ripe.net> Begin forwarded message: > From: Andreas Strikos > Date: March 30, 2011 4:21:09 PM GMT+02:00 > To: Woeber at CC.UniVie.ac.at > Subject: Re: [atlas]"perceived" downtime of probe? > > Hi Wilfried, > > your probe is fine! > Last history uptime values are not propagated immediately to the central database by design. > That is why there were some "fault" calculations for small time for your probe. > Now that the latest uptime values are there, everything seems fine I believe. > > Regards, > Andreas > > On Mar 30, 2011, at 3:52 PM, Wilfried Woeber, UniVie/ACOnet wrote: > >> Hi Team, >> >> could you please have a look at the data for my 414, >> the "uptime" info claims a downtime of 7d, 16h, 51m, >> disconnected at 2011-03-22 20:50:26 UTC, up again at 2011-03-30 13:41:40 UTC. >> >> (the reason for the very short(!) interruption *today* was the need to move >> the USB cable to a different outlet...) [1] >> >> At the same time there is *no* loss of measurement data for this period!? >> >> Has anyone else seen such a situation recently? >> Wilfried >> >> [1] it would really be "cool" to ship future probes with some sort of >> "Y"-cable which w|should allow moving probes without loss of power, >> and/or to connect one plug to a UPS-fed outlet :-) >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vnaumov at ripe.net Wed Mar 30 17:02:20 2011 From: vnaumov at ripe.net (Viktor Naoumov) Date: Wed, 30 Mar 2011 17:02:20 +0200 Subject: [atlas]time base / synch for the "lst two hours" graphs? In-Reply-To: <4D9338FF.2090804@CC.UniVie.ac.at> References: <4D9338FF.2090804@CC.UniVie.ac.at> Message-ID: <4D9345FC.7070608@ripe.net> Hi Wilfried, We cannot display synchronized graphs at the last measurement time position because RRDs are updated only when the measurement data comes from the probe. Probes are allowed to send data not synchronous for all the measurements. As it implemented currently, we stop the graph at the time stamp of the last measurement. We can do it using current time, in this case graphs will be aligned, but unreceived data will be displayed as a gray area, that's what we do not really want. From your email I can guess that you are fetching graphs for your own page. In this case you can set the end time which ever you want: http://atlas.ripe.net/atlas/rrd.png?prb_id=3&msm_id=1001&type=minutely&*end=now* or even allow it to be, for example, 15 minutes older: http://atlas.ripe.net/atlas/rrd.png?prb_id=3&msm_id=1001&type=minutely&*end=now-15min* now is UTC Best regards, /vty On 03/30/2011 04:06 PM, Wilfried Woeber, UniVie/ACOnet wrote: > I just noticed that the various graphs for the "last 2 hours" display > seem to be based on different clocks or update cycles (delta = some 25m). > > Should these graphs be "synchronised"? > > From a UI-perspective it would certainly be a bonus to have them aligned, > at least for one probe. > > All the best, > Wilfried. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Woeber at CC.UniVie.ac.at Wed Mar 30 17:59:48 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 30 Mar 2011 15:59:48 +0000 Subject: [atlas]time base / synch for the "lst two hours" graphs? In-Reply-To: <4D9345FC.7070608@ripe.net> References: <4D9338FF.2090804@CC.UniVie.ac.at> <4D9345FC.7070608@ripe.net> Message-ID: <4D935374.5030906@CC.UniVie.ac.at> Hi Viktor, thanks for the explanation! Viktor Naoumov wrote: > Hi Wilfried, > > We cannot display synchronized graphs at the last measurement time > position because RRDs are updated only when the measurement data comes > from the probe. Probes are allowed to send data not synchronous for all > the measurements. > > As it implemented currently, we stop the graph at the time stamp of the > last measurement. We can do it using current time, in this case graphs > will be aligned, but unreceived data will be displayed as a gray area, > that's what we do not really want. I agree :-) > From your email I can guess that you are fetching graphs for your own page. No, not yet. I was looking at the various graphs in the pop-up tabs for my probe. Thus I noticed that the time periods for those graphs were different. > In this case you can set the end time which ever you want: > > http://atlas.ripe.net/atlas/rrd.png?prb_id=3&msm_id=1001&type=minutely&*end=now* 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... > or even allow it to be, for example, 15 minutes older: > > http://atlas.ripe.net/atlas/rrd.png?prb_id=3&msm_id=1001&type=minutely&*end=now-15min* > > > now is UTC :-) > Best regards, > > /vty Thanks, best regards, Wilfried. > On 03/30/2011 04:06 PM, Wilfried Woeber, UniVie/ACOnet wrote: > >> I just noticed that the various graphs for the "last 2 hours" display >> seem to be based on different clocks or update cycles (delta = some 25m). >> >> Should these graphs be "synchronised"? >> >> From a UI-perspective it would certainly be a bonus to have them >> aligned, >> at least for one probe. >> >> All the best, >> Wilfried. >> > > From vnaumov at ripe.net Wed Mar 30 22:24:33 2011 From: vnaumov at ripe.net (Viktor Naoumov) Date: Wed, 30 Mar 2011 22:24:33 +0200 Subject: [atlas]time base / synch for the "lst two hours" graphs? In-Reply-To: <4D935374.5030906@CC.UniVie.ac.at> References: <4D9338FF.2090804@CC.UniVie.ac.at> <4D9345FC.7070608@ripe.net> <4D935374.5030906@CC.UniVie.ac.at> Message-ID: <4D939181.7080203@ripe.net> 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 robert at ripe.net Thu Mar 31 09:55:11 2011 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 31 Mar 2011 09:55:11 +0200 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: <4D94335F.609@ripe.net> Please also note that RRD is just the current visualisation tool. We'd also like to give you access to "your data" -- ie. data collected by your probe so that you can do your own graphs if you want to. Regards, Robert On 2011.03.30. 22:24, 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 >