This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ripe-atlas@ripe.net/
[RIPE Atlas Ambassadors] News and Happy Holidays!
- Previous message (by thread): [RIPE Atlas Ambassadors] News and Happy Holidays!
- Next message (by thread): [RIPE Atlas Ambassadors] LED status for RIPE probes
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Gil Bahat
gil at magisto.com
Sun Dec 27 13:46:40 CET 2015
On Fri, Dec 25, 2015 at 9:56 AM, Nishal Goburdhan <nishal at controlfreak.co.za > wrote: > On 24 Dec 2015, at 16:22, Gil Bahat wrote: > > > 3. People will chip in if explained that the credits will help our company >> deliver better service to our users. However, the current credit system >> forces me to register it under my name and not theirs. it would be better >> if at registration point, a user could permanently assign credits to a >> recipient or group. >> > > i’m not sure why this is the case. i have exactly one probe registered in > my name, and have distributed a few hundred. > it’s easy enough, in an organisation, to have a general alias (eg. > ripe-probes at example.isp.com) to which something like the network > team/whomever can have access to. presumably this is a trusted group so > tracking things like credits usage, etc. is a non-issue? > > > 4. Building up on the above, perhaps gamification and groups are a good way >> to encourage adoption. Seeing how many credits your group generated makes >> it a bit like a (positive) contest. >> 5. I have found trouble with getting coverage for mobile (3G/4G) networks. >> there are very few setups in which these are gateway'd to ethernet. as a >> case in point, we have a USB 3G adaptor as backup in the company and no >> one >> would mind if it's connected to a probe when it's unused (which is 99.99% >> of the time), but there is no physical port available for this (and >> possibly no CDC ethernet driver). another option might be to allow the >> probes to interface with mobile phones somehow, which would entail >> occasional access to these networks when a paired phone is nearby, but >> perhaps it would be better than nothing. >> > > my general rule of thumb has been to advise *AGAINST* deployment in mobile > networks (or more correctly, against deployment in usage-based-billing > networks), unless the organisation/individual understands the costs > attached to this. since the majority of mobile accounts are limited to > some silly data-cap, after which it becomes exorbitantly expensive, and > even a relatively idle probe, can consume up to 2.5GB of data a month. > that’s a nasty surprise for someone that wasn’t expecting to see this data > usage. ymmv. > > tricky thing that, because those are networks with poor ATLAS coverage and in high demand (at least for us, we're a mobile app developer). I had 2 ways to approach this: 1. try to utilize idle backup connections at companies which otherwise use 3g/4g as a passive backup. I believe I'm going to have 2 such installations soon. 2. appeal directly to mobile operators to donate the equipment and bandwidth to host these probes. this is harder because there is no spare USB port on the probes themselves, so they either need to place them at their NOC (so it's not as representative) or bear the costs themselves. insofar no luck yet, though i'm trying to pull some leverage as a potential customer. 3. of course, if you're lucky enough to have no-cap plans in your country, you might be able to convince someone to do it. Gil > —n. > -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/ripe-atlas-ambassadors/attachments/20151227/db194bb0/attachment.html>
- Previous message (by thread): [RIPE Atlas Ambassadors] News and Happy Holidays!
- Next message (by thread): [RIPE Atlas Ambassadors] LED status for RIPE probes
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]