Re: [cacti-announce] Cacti 0.8.6j Released (fwd)
On 2/7/07, Ray Burkholder [EMAIL PROTECTED] wrote: Going back to this thread, http://www.kx.com/ deals in financial transaction databases where they store millions of ticks. They appear to have a transactional based language with a solution that appears to be robust and fail resistant. I'm sure it has a price tag that goes along with the capabilities. Anyone encountered this before? hmm, that is quite interesting. and apparently people out there _are_ using it for things like counter values and what not - based on their FAQ. I'd absolutely love to know more about the algorithms and math behind something like kdb+
Time Series databases
Going back to this thread, http://www.kx.com/ deals in financial transaction databases where they store millions of ticks. They appear to have a transactional based language with a solution that appears to be robust and fail resistant. hmm, that is quite interesting. and apparently people out there _are_ using it for things like counter values and what not - based on their FAQ. I'd absolutely love to know more about the algorithms and math behind something like kdb+ KX publish a bunch of information about their product. Their lineage goes back to APL and the J language, both of which found most of their users in financial services. However, the general issue of time-series databases is more interesting. Google will take you to lots of research using keywords like: time-series database delta wavelet search indexing maxima Of course, don't use them all at once. To give you a flavor of the stuff that people have done, here is a slide presentation on compression and indexing that does not use averages like RRD does: http://www.cs.cmu.edu/~eugene/research/talks/major-extrema.ppt In addition to Google, it is a good idea to search CiteSeer http://citeseer.ist.psu.edu/ because it allows you to quickly track down references to other papers so you can read them all as a set. I don't think there are any full-blown open-source implementations that you could integrate into your own systems. There is stuff like Metakit http://www.equi4.com/metakit.html which stores data by column rather than by row. And people who have thought about how to efficiently store time-series probably cobbled together their own systems using bsddb or HDF5. If you are stuck in the SQL world, then check out these articles on star and snowflake schemas. http://en.wikipedia.org/wiki/Snowflake_schema http://en.wikipedia.org/wiki/Star_schema and follow up the references at the bottom of the page.
Re: Anyone with SMTP clue at Verizon Wireless / Vtext?
On Wed, Feb 07, 2007 at 06:25:41PM -0800, Mike Lyon wrote: Their gateway is blocking mail from my host. Of course, there is no clueful contact info on their webpage... I know you asked for off-list, but since this (mail to Verizon refused) is a recurring problem, I'm sending this on-list as well. Anyone who has trouble sending mail to Verizon should check their own *incoming* mail logs for connections coming from systems in 206.46.0.0/16 (GTEN-206-46), most likely 206.46.252.0/24, whose names look something like: 206.46.252.147 sv114pub.verizon.net 206.46.252.148 sv124pub.verizon.net 206.46.252.149 sv134pub.verizon.net If you're refusing those connections or blocking mail RCPT TO attempts from them, then Verizon will probably refuse your outbound SMTP traffic to them. This may not be the problem you're facing; or it may not be the only problem you're facing. But it's easy enough to check and rule out if that's the case. ---Rsk p.s. *Why* is this happening? Because Verizon has deployed a very ill-considered anti-spam technique (callbacks AKA sender address verification) that serves three primary functions: first, it forcibly shifts the costs of Verizon's spam control onto third parties; second, it provides a spam support service; and third, it provides a free, anonymizing, scalable DDoS service.
Re: Hackers hit key Internet traffic computers
On 7-Feb-2007, at 15:24, virendra rode // wrote: Looking at these attacks, F in particular, if my memory serves me correct, there are 35 f-root anycast nodes deployed. Maybe this helped in some respect. Dave Knight's lightning talk in Toronto seemed to indicate that F's anycast platform did a good job at sinking the bulk of the attack traffic in Seoul and Beijing, and that the spill-over from the region was mopped up easily by the very large nodes in California. Most other locations that have a local F-root server saw very little impact. Isolation of attack traffic seems like a big help to me. Then again, I like to see what kind of analysis comes out from the collected data. Joe
Re: Time Series databases
On 2/8/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Going back to this thread, http://www.kx.com/ deals in financial transaction databases where they store millions of ticks. They appear to have a transactional based language with a solution that appears to be robust and fail resistant. hmm, that is quite interesting. and apparently people out there _are_ using it for things like counter values and what not - based on their FAQ. I'd absolutely love to know more about the algorithms and math behind something like kdb+ KX publish a bunch of information about their product. Their lineage goes back to APL and the J language, both of which found most of their users in financial services. However, the general issue of time-series databases is more interesting. Google will take you to lots of research using keywords like: time-series database delta wavelet search indexing maxima Of course, don't use them all at once. To give you a flavor of the stuff that people have done, here is a slide presentation on compression and indexing that does not use averages like RRD does: http://www.cs.cmu.edu/~eugene/research/talks/major-extrema.ppt In addition to Google, it is a good idea to search CiteSeer http://citeseer.ist.psu.edu/ because it allows you to quickly track down references to other papers so you can read them all as a set. I don't think there are any full-blown open-source implementations that you could integrate into your own systems. There is stuff like Metakit http://www.equi4.com/metakit.html which stores data by column rather than by row. And people who have thought about how to efficiently store time-series probably cobbled together their own systems using bsddb or HDF5. If you are stuck in the SQL world, then check out these articles on star and snowflake schemas. http://en.wikipedia.org/wiki/Snowflake_schema http://en.wikipedia.org/wiki/Star_schema and follow up the references at the bottom of the page. There have been numerous technical discussions over at EliteTrader.com about tick database implementations using a variety of technologies from with various pros and cons of SQL, KX, Vhayu, Times Ten, Hibernate, and HDF5 a must read for anyone interested. The threads can be found on elite trader automated trading forums http://www.elitetrader.com/vb/showthread.php?s=threadid=81345perpage=6pagenumber=1 -- Rodrick R. Brown
MSN/Hotmail Email Admin..
MSN / Hotmail Email admin, please contact me off-list. Thanks, James
Question about SLAs
Other than give them the bum's rush! what do you do when a vendor is a PITA about SLAs for outages? Obviously there's not enough on the table to get lawyers involved, but it's aggravating when first they act like they lost your SLA request, then claim their logs don't match your logs in some significant way, then try to avoid returning calls to find out what got decided about disputes I guess hoping you'll give up, etc. It's lousy game theory if the vendor just wants to insist their logs are very different than the customer's (highly detailed logs), for example, short of bolting, which there might be other reasons to not want to do except as a last resort, like the cost would be a lot more than the SLAs in question. But where's the leverage? I hope this is operational enough for this list, if not feel free point me somewhere else. -- -Barry Shein The World | [EMAIL PROTECTED] | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD| Login: Nationwide Software Tool Die| Public Access Internet | SINCE 1989 *oo*
RE: Question about SLAs
Find a new vendor is certainly one solution. Regards, chad From: [EMAIL PROTECTED] on behalf of Barry Shein Sent: Thu 2/8/2007 3:00 PM To: nanog@merit.edu Subject: Question about SLAs Other than give them the bum's rush! what do you do when a vendor is a PITA about SLAs for outages? Obviously there's not enough on the table to get lawyers involved, but it's aggravating when first they act like they lost your SLA request, then claim their logs don't match your logs in some significant way, then try to avoid returning calls to find out what got decided about disputes I guess hoping you'll give up, etc. It's lousy game theory if the vendor just wants to insist their logs are very different than the customer's (highly detailed logs), for example, short of bolting, which there might be other reasons to not want to do except as a last resort, like the cost would be a lot more than the SLAs in question. But where's the leverage? I hope this is operational enough for this list, if not feel free point me somewhere else. -- -Barry Shein The World | [EMAIL PROTECTED] | http://www.TheWorld.com http://www.theworld.com/ Purveyors to the Trade | Voice: 800-THE-WRLD| Login: Nationwide Software Tool Die| Public Access Internet | SINCE 1989 *oo*
Re: Question about SLAs
On Thu, 08 Feb 2007 19:09:34 PST, Chad Skidmore said: Find a new vendor is certainly one solution. Your current vendor probably knows how much it would cost for you to move to another vendor (quite possibly to more significant digits than *you* know). They also know exactly how much they're making/losing on SLA issues, and what percent of the move cost you're willing to tolerate - there's probably very few of us that can get away with being righteous and principled and spending $100K on a move to a new vendor over a $980 SLA issue. And even those of us who *can* do that probably can't do it a second time anytime soon. Of course, YMMV - spending $25K to get out of a contract with somebody who's already shafted you for $12K of SLA rebates and shows no sign of stopping is probably justifiable by almost all of us But I think Barry was asking specifically about the vendor who nickels and dimes you precisely because they know it's not enough to make a business case for moving. pgpEIZZ43Mdit.pgp Description: PGP signature
RE: Question about SLAs
Agreed, any termination liability is something to consider. You also need to consider the impact to your business that the SLA violations is causing and how that might translate to dollars. Documentation is going to be key if the vendor is nickel and diming you. If you have solid documentation of a pattern of behavior that is contrary to the spirit (and hopefully letter) of your SLA the vendor is probably not going to push the termination liability. They may not refund for SLA violations but they also would probably not push the termination liability too far. SLA claims can turn into a game of chicken at times. If you honestly feel your position is solid, don't blink. Good luck, Chad -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, February 08, 2007 7:29 PM To: Chad Skidmore Cc: Barry Shein; nanog@merit.edu Subject: Re: Question about SLAs On Thu, 08 Feb 2007 19:09:34 PST, Chad Skidmore said: Find a new vendor is certainly one solution. Your current vendor probably knows how much it would cost for you to move to another vendor (quite possibly to more significant digits than *you* know). They also know exactly how much they're making/losing on SLA issues, and what percent of the move cost you're willing to tolerate - there's probably very few of us that can get away with being righteous and principled and spending $100K on a move to a new vendor over a $980 SLA issue. And even those of us who *can* do that probably can't do it a second time anytime soon. Of course, YMMV - spending $25K to get out of a contract with somebody who's already shafted you for $12K of SLA rebates and shows no sign of stopping is probably justifiable by almost all of us But I think Barry was asking specifically about the vendor who nickels and dimes you precisely because they know it's not enough to make a business case for moving.
RE: Question about SLAs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 An SLA is a contract. A contract is... a contract. Read it carefully. :-) - - ferg - -- Chad Skidmore [EMAIL PROTECTED] wrote: Agreed, any termination liability is something to consider. You also need to consider the impact to your business that the SLA violations is causing and how that might translate to dollars. Documentation is going to be key if the vendor is nickel and diming you. If you have solid documentation of a pattern of behavior that is contrary to the spirit (and hopefully letter) of your SLA the vendor is probably not going to push the termination liability. They may not refund for SLA violations but they also would probably not push the termination liability too far. SLA claims can turn into a game of chicken at times. If you honestly feel your position is solid, don't blink. Good luck, Chad - -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, February 08, 2007 7:29 PM To: Chad Skidmore Cc: Barry Shein; nanog@merit.edu Subject: Re: Question about SLAs On Thu, 08 Feb 2007 19:09:34 PST, Chad Skidmore said: Find a new vendor is certainly one solution. Your current vendor probably knows how much it would cost for you to move to another vendor (quite possibly to more significant digits than *you* know). They also know exactly how much they're making/losing on SLA issues, and what percent of the move cost you're willing to tolerate - there's probably very few of us that can get away with being righteous and principled and spending $100K on a move to a new vendor over a $980 SLA issue. And even those of us who *can* do that probably can't do it a second time anytime soon. Of course, YMMV - spending $25K to get out of a contract with somebody who's already shafted you for $12K of SLA rebates and shows no sign of stopping is probably justifiable by almost all of us But I think Barry was asking specifically about the vendor who nickels and dimes you precisely because they know it's not enough to make a business case for moving. [snip] -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFFzAbKq1pz9mNUZTMRAqTkAKCuVOT8/ZMIWeWlh05YTfbxXFouKgCgm0Li 56DDOcg1G9HzrlM7kzcMtxE= =i2LJ -END PGP SIGNATURE- -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
