Amazon High I/O instances

Started by Sébastien Lorionover 13 years ago44 messagesgeneral
Jump to latest
#1Sébastien Lorion
sl@thestrangefactory.com

Hello,

Since Amazon has added new high I/O instance types and EBS volumes, anyone
has done some benchmark of PostgreSQL on them ?

http://perspectives.mvdirona.com/2012/07/20/IOPerformanceNoLongerSucksInTheCloud.aspx
http://perspectives.mvdirona.com/2012/08/01/EBSProvisionedIOPSOptimizedInstanceTypes.aspx
http://aws.typepad.com/aws/2012/08/fast-forward-provisioned-iops-ebs.html

I will be testing my app soon, but was curious to know if others have done
some tests so I can compare / have a rough idea to what to expect. Looking
on Google, I found an article about MySQL (
http://palominodb.com/blog/2012/07/24/palomino-evaluates-amazon%E2%80%99s-new-high-io-ssd-instances),
but nothing about PostgresSQL.

Thanks !

Sébastien

#2Vincent Veyron
vv.lists@wanadoo.fr
In reply to: Sébastien Lorion (#1)
Re: Amazon High I/O instances

Le mardi 21 aoᅵt 2012 ᅵ 01:33 -0400, Sᅵbastien Lorion a ᅵcrit :

Since Amazon has added new high I/O instance types and EBS volumes,
anyone has done some benchmark of PostgreSQL on them ?

I wonder : is there a reason why you have to go through the complexity
of such a setup, rather than simply use bare metal and get good
performance with simplicity?

For instance, the dedibox I use for my app (visible in sig) costs 14,00
euros/month, and sits at .03% load average with 5 active users; you can
admin it like a home pc.

--
Vincent Veyron
http://marica.fr/
Gestion informatique des sinistres d'assurances et des dossiers contentieux pour le service juridique

#3Vincent Veyron
vv.lists@wanadoo.fr
In reply to: Sébastien Lorion (#1)
Re: Amazon High I/O instances

Le mardi 21 aoᅵt 2012 ᅵ 01:33 -0400, Sᅵbastien Lorion a ᅵcrit :

Since Amazon has added new high I/O instance types and EBS volumes,
anyone has done some benchmark of PostgreSQL on them ?

I wonder : is there a reason why you have to go through the complexity
of such a setup, rather than simply use bare metal and get good
performance with simplicity?

For instance, the dedibox I use for my app (visible in sig) costs 14,00
euros/month, and sits at .03% load average with 5 active users; you can
admin it like a home pc.

--
Vincent Veyron
http://marica.fr/
Gestion informatique des sinistres d'assurances et des dossiers contentieux pour le service juridique

#4Oliver Kohll - Mailing Lists
oliver.lists@gtwm.co.uk
In reply to: Vincent Veyron (#3)
Re: Amazon High I/O instances

On 21 Aug 2012, at 13:32, Vincent Veyron <vv.lists@wanadoo.fr> wrote:

Since Amazon has added new high I/O instance types and EBS volumes,
anyone has done some benchmark of PostgreSQL on them ?

I wonder : is there a reason why you have to go through the complexity
of such a setup, rather than simply use bare metal and get good
performance with simplicity?

For instance, the dedibox I use for my app (visible in sig) costs 14,00
euros/month, and sits at .03% load average with 5 active users; you can
admin it like a home pc.

This is a general 'cloud or dedicated' question, I won't go into it but I believe cloud proponents cite management ease, scalability etc. I'm sure there's a place for every type of hosting. However I would be interested in hearing some experiences of PostgreSQL on an Amazon high I/O instance, given a client has just proposed running on one. If there are none forthcoming in the short term I may be in a position to provide some results myself in a month or two.

Oliver Kohll
www.agilebase.co.uk

#5David Boreham
david_list@boreham.org
In reply to: Oliver Kohll - Mailing Lists (#4)
Re: Amazon High I/O instances

On 8/21/2012 7:10 AM, Oliver Kohll - Mailing Lists wrote:

This is a general 'cloud or dedicated' question, I won't go into it
but I believe cloud proponents cite management ease, scalability etc.
I'm sure there's a place for every type of hosting. However I would be
interested in hearing some experiences of PostgreSQL on an Amazon high
I/O instance, given a client has just proposed running on one. If
there are none forthcoming in the short term I may be in a position to
provide some results myself in a month or two.

Amazon don't say what vendor's SSDs they are using, which is a little
worrying to me -- when we deployed our SSD-based machines last year,
much work was done to address the risk of write endurance problems. Now,
an AWS instance and its ephemeral storage isn't expected to live forever
(keep that in mind when storing data on one!)
so perhaps one can ignore write endurance as a concern in this case
since we'd already be worried about (and have a plan to address) "entire
machine endurance".

For sure performance on these instances for any I/O limited application
is going to be great.
I have a friend who is looking at them for his "big data" analytics
application which spends most of its time sorting Tb sized files.

#6David Boreham
david_list@boreham.org
In reply to: Vincent Veyron (#3)
Re: Amazon High I/O instances

On 8/21/2012 2:18 AM, Vincent Veyron wrote:

I wonder : is there a reason why you have to go through the complexity
of such a setup, rather than simply use bare metal and get good
performance with simplicity?

In general I agree -- it is much (much!) cheaper to buy tin and deploy
yourself vs any of the current cloud services.

However, there are plenty of counterexample use cases : for example what
if you want one of these machines for a week only?
Another one : what if you are a venture capitalist funding 10 companies
with questionable business models where you expect only one to succeed?
AWS saves you from the headache of selling 500 machines on eBay...

#7Merlin Moncure
mmoncure@gmail.com
In reply to: Sébastien Lorion (#1)
Re: Amazon High I/O instances

On Tue, Aug 21, 2012 at 12:33 AM, Sébastien Lorion
<sl@thestrangefactory.com> wrote:

Hello,

Since Amazon has added new high I/O instance types and EBS volumes, anyone
has done some benchmark of PostgreSQL on them ?

http://perspectives.mvdirona.com/2012/07/20/IOPerformanceNoLongerSucksInTheCloud.aspx
http://perspectives.mvdirona.com/2012/08/01/EBSProvisionedIOPSOptimizedInstanceTypes.aspx
http://aws.typepad.com/aws/2012/08/fast-forward-provisioned-iops-ebs.html

I will be testing my app soon, but was curious to know if others have done
some tests so I can compare / have a rough idea to what to expect. Looking
on Google, I found an article about MySQL
(http://palominodb.com/blog/2012/07/24/palomino-evaluates-amazon%E2%80%99s-new-high-io-ssd-instances),
but nothing about PostgresSQL.

here's a datapoint, stock config:
pgbench -i -s 500
pgbench -c 16 -T 60
number of transactions actually processed: 418012
tps = 6962.607292 (including connections establishing)
tps = 6973.154593 (excluding connections establishing)

not too shabby. this was run by a friend who is evaluating high i/o
instances for their high load db servers. we didn't have time to
kick off a high scale read only test unfortunately.

Regarding 'AWS vs bare metal', I think high i/o instances full a huge
niche in their lineup. Dollar for dollar, I'm coming around to the
point of view that dealing with aws is a cheaper/more effective
solution than renting out space from a data center or (even worse)
running your own data center unless you're very large or have other
special requirements. Historically the problem with AWS is that you
had no solution for highly transaction bound systems which forced you
to split your environment which ruined most of the benefit, and they
fixed that.

merlin

#8Vincent Veyron
vv.lists@wanadoo.fr
In reply to: Merlin Moncure (#7)
Re: Amazon High I/O instances

Le mardi 21 aoᅵt 2012 ᅵ 09:36 -0500, Merlin Moncure a ᅵcrit :

here's a datapoint, stock config:
pgbench -i -s 500
pgbench -c 16 -T 60
number of transactions actually processed: 418012
tps = 6962.607292 (including connections establishing)
tps = 6973.154593 (excluding connections establishing)

not too shabby. this was run by a friend who is evaluating high i/o
instances for their high load db servers. we didn't have time to
kick off a high scale read only test unfortunately.

Regarding 'AWS vs bare metal', I think high i/o instances full a huge
niche in their lineup. Dollar for dollar, I'm coming around to the
point of view that dealing with aws is a cheaper/more effective
solution than renting out space from a data center or (even worse)
running your own data center unless you're very large or have other
special requirements. Historically the problem with AWS is that you
had no solution for highly transaction bound systems which forced you
to split your environment which ruined most of the benefit, and they
fixed that.

Hi Merlin,

I am sure you can get good performance with these.

I simply focused on the part where seb said he was testing his app, and
since you can get some really high data throughput (by my very modest
standards anyway) with a good machine, I wondered why he did it.

Maybe seb is planning for an application that already has hundreds of
users after all, I did oversee that option.

To Sᅵbastien : please use 'reply all' to send your reply to the list

Le mardi 21 aoᅵt 2012 ᅵ 10:29 -0400, Sᅵbastien Lorion a ᅵcrit :
Could you elaborate on the complexity you mention ? Setting up a machine
on Amazon, even with a script, is quite simple. As for the pricing you
give, it can be matched on Amazon using Micro or small instances, which
would be adequate given your load average.

Well, it _has_ to be more complicated to use AWS than a bare machine,
because of the added layer?

--
Vincent Veyron
http://vincentveyron.com/
Gestion informatique des sinistres d'assurances et des dossiers contentieux pour le service juridique

#9Sébastien Lorion
sl@thestrangefactory.com
In reply to: Vincent Veyron (#8)
Re: Amazon High I/O instances

Oops sorry, I thought I did hit reply all.

I am not sure this mailing list is the right place to have this debate
(assuming it is needed, there are plenty of articles stating the benefits
of using the cloud), so I will simply answer that you pay the cost of the
added layer up front (mostly scripting the Amazon API and batch
configuration), but it saves you a ton of time even in the short term and
even for a 2-3 machines setup. Besides, launching and shutting down 10's or
100's of new instances of a server to answer a burst of requests is hardly
feasible on dedicated hardware, nor is it cheap to rent servers in
different physical locations with some respectable SLA.

Sébastien

On Tue, Aug 21, 2012 at 1:16 PM, Vincent Veyron <vv.lists@wanadoo.fr> wrote:

Show quoted text

Le mardi 21 août 2012 à 09:36 -0500, Merlin Moncure a écrit :

here's a datapoint, stock config:
pgbench -i -s 500
pgbench -c 16 -T 60
number of transactions actually processed: 418012
tps = 6962.607292 (including connections establishing)
tps = 6973.154593 (excluding connections establishing)

not too shabby. this was run by a friend who is evaluating high i/o
instances for their high load db servers. we didn't have time to
kick off a high scale read only test unfortunately.

Regarding 'AWS vs bare metal', I think high i/o instances full a huge
niche in their lineup. Dollar for dollar, I'm coming around to the
point of view that dealing with aws is a cheaper/more effective
solution than renting out space from a data center or (even worse)
running your own data center unless you're very large or have other
special requirements. Historically the problem with AWS is that you
had no solution for highly transaction bound systems which forced you
to split your environment which ruined most of the benefit, and they
fixed that.

Hi Merlin,

I am sure you can get good performance with these.

I simply focused on the part where seb said he was testing his app, and
since you can get some really high data throughput (by my very modest
standards anyway) with a good machine, I wondered why he did it.

Maybe seb is planning for an application that already has hundreds of
users after all, I did oversee that option.

To Sébastien : please use 'reply all' to send your reply to the list

Le mardi 21 août 2012 à 10:29 -0400, Sébastien Lorion a écrit :
Could you elaborate on the complexity you mention ? Setting up a machine
on Amazon, even with a script, is quite simple. As for the pricing you
give, it can be matched on Amazon using Micro or small instances, which
would be adequate given your load average.

Well, it _has_ to be more complicated to use AWS than a bare machine,
because of the added layer?

--
Vincent Veyron
http://vincentveyron.com/
Gestion informatique des sinistres d'assurances et des dossiers
contentieux pour le service juridique

#10Craig Ringer
craig@2ndquadrant.com
In reply to: David Boreham (#6)
Re: Amazon High I/O instances

On 08/21/2012 09:40 PM, David Boreham wrote:

On 8/21/2012 2:18 AM, Vincent Veyron wrote:

I wonder : is there a reason why you have to go through the complexity
of such a setup, rather than simply use bare metal and get good
performance with simplicity?

In general I agree -- it is much (much!) cheaper to buy tin and deploy
yourself vs any of the current cloud services.

However, there are plenty of counterexample use cases : for example what
if you want one of these machines for a week only?
Another one : what if you are a venture capitalist funding 10 companies
with questionable business models where you expect only one to succeed?
AWS saves you from the headache of selling 500 machines on eBay...

Dedibox appears to be a hosting company that offers dedicated machines.

He appears to be suggesting that buying access to real hardware in a
datacenter (if not buying the hardware yourself) is more cost effective
and easier to manage than using "cloud" style services with more
transient hosts like EC2 offers. At least that's how I understood it.
Vincent?

I wasn't sure what Vincent meant until I did an `mtr` on his host
address, either.

http://dedibox.fr/

redirects to

http://www.online.net/

A look at their product page suggests that they're at least claiming the
machines are dedicated:

http://www.online.net/serveur-dedie/offre-dedibox-sc.xhtml

running Via Nano (Nano U2250) CPUs on Dell VX11-VS8 machines. The VS8
appears to be a blade:

http://en.community.dell.com/dell-blogs/direct2dell/b/direct2dell/archive/2009/05/19/dell-launches-quot-fortuna-quot-via-nano-based-server-for-hyperscale-customers.aspx

http://www.flickr.com/photos/netbooknews/3537912243/

so yeah, a dedicated server for ᅵ15/month. That's *AWESOME* when you
mostly need storage and you don't care about performance or storage
reliability; it's a local HDD so you get great gobs of storage w/o
paying per GB.

--
Craig Ringer

#11Vincent Veyron
vv.lists@wanadoo.fr
In reply to: Craig Ringer (#10)
Re: Amazon High I/O instances

Le mercredi 22 aoᅵt 2012 ᅵ 13:15 +0800, Craig Ringer a ᅵcrit :

He appears to be suggesting that buying access to real hardware in a
datacenter (if not buying the hardware yourself) is more cost effective
and easier to manage than using "cloud" style services with more
transient hosts like EC2 offers. At least that's how I understood it.

Hi Craig,

Actually, my comments about costs were misleading : I simply reacted to
the fact that the OP wanted to test his application for high
performance, and thought that it would be easier with bare metal rather
than with AWS, because you have less parameters to control this way.

Also, I'll admit that I jumped the gun without reading about the SSD
offer by Amazon. Still, I would test first with a machine that I
control, but it maybe that Sᅵbastien already did that.

I am curious to know what kind of application requires 10s to 100s of
instances with a PostgreSQL database, because that could get unwieldy
with big data (which I assumed from the high performance specification)

--
Vincent Veyron
http://marica.fr/
Gestion informatique des sinistres d'assurances et des dossiers contentieux pour le service juridique

#12Sébastien Lorion
sl@thestrangefactory.com
In reply to: Vincent Veyron (#11)
Re: Amazon High I/O instances

Vincent, I would appreciate that you stop assuming things based on zero
information about what I am doing. I understand that you are trying to be
helpful, but I can assure you that going bare-metal only does not make any
sense in my context.

Sébastien

On Wed, Aug 22, 2012 at 12:44 PM, Vincent Veyron <vv.lists@wanadoo.fr>wrote:

Show quoted text

Le mercredi 22 août 2012 à 13:15 +0800, Craig Ringer a écrit :

He appears to be suggesting that buying access to real hardware in a
datacenter (if not buying the hardware yourself) is more cost effective
and easier to manage than using "cloud" style services with more
transient hosts like EC2 offers. At least that's how I understood it.

Hi Craig,

Actually, my comments about costs were misleading : I simply reacted to
the fact that the OP wanted to test his application for high
performance, and thought that it would be easier with bare metal rather
than with AWS, because you have less parameters to control this way.

Also, I'll admit that I jumped the gun without reading about the SSD
offer by Amazon. Still, I would test first with a machine that I
control, but it maybe that Sébastien already did that.

I am curious to know what kind of application requires 10s to 100s of
instances with a PostgreSQL database, because that could get unwieldy
with big data (which I assumed from the high performance specification)

--
Vincent Veyron
http://marica.fr/
Gestion informatique des sinistres d'assurances et des dossiers
contentieux pour le service juridique

#13Andrew Hannon
ahannon@fiksu.com
In reply to: Sébastien Lorion (#12)
Re: Amazon High I/O instances

Just looking into High IO instances for a DB deployment. In order to get past 1TB, we are looking at RAID-0. I have heard (http://hackerne.ws/item?id=4266119) there might be a problem if TRIM isn't supported. Does anyone know if it is and has anyone used RAID-0 on these instances? (Linux of course…)

Show quoted text

On Aug 21, 2012, at 9:36 AM, Merlin Moncure wrote:

On Tue, Aug 21, 2012 at 12:33 AM, Sébastien Lorion
<sl@thestrangefactory.com> wrote:

Hello,

Since Amazon has added new high I/O instance types and EBS volumes, anyone
has done some benchmark of PostgreSQL on them ?

http://perspectives.mvdirona.com/2012/07/20/IOPerformanceNoLongerSucksInTheCloud.aspx
http://perspectives.mvdirona.com/2012/08/01/EBSProvisionedIOPSOptimizedInstanceTypes.aspx
http://aws.typepad.com/aws/2012/08/fast-forward-provisioned-iops-ebs.html

I will be testing my app soon, but was curious to know if others have done
some tests so I can compare / have a rough idea to what to expect. Looking
on Google, I found an article about MySQL
(http://palominodb.com/blog/2012/07/24/palomino-evaluates-amazon%E2%80%99s-new-high-io-ssd-instances),
but nothing about PostgresSQL.

here's a datapoint, stock config:
pgbench -i -s 500
pgbench -c 16 -T 60
number of transactions actually processed: 418012
tps = 6962.607292 (including connections establishing)
tps = 6973.154593 (excluding connections establishing)

not too shabby. this was run by a friend who is evaluating high i/o
instances for their high load db servers. we didn't have time to
kick off a high scale read only test unfortunately.

Regarding 'AWS vs bare metal', I think high i/o instances full a huge
niche in their lineup. Dollar for dollar, I'm coming around to the
point of view that dealing with aws is a cheaper/more effective
solution than renting out space from a data center or (even worse)
running your own data center unless you're very large or have other
special requirements. Historically the problem with AWS is that you
had no solution for highly transaction bound systems which forced you
to split your environment which ruined most of the benefit, and they
fixed that.

merlin

#14Alan Hodgson
ahodgson@simkin.ca
In reply to: Andrew Hannon (#13)
Re: Amazon High I/O instances

On Wednesday, August 22, 2012 04:10:01 PM Andrew Hannon wrote:

Just looking into High IO instances for a DB deployment. In order to get
past 1TB, we are looking at RAID-0. I have heard
(http://hackerne.ws/item?id=4266119) there might be a problem if TRIM isn't
supported. Does anyone know if it is and has anyone used RAID-0 on these
instances? (Linux of course…)

Just use LVM striping. If it turns out to be an issue; that seems to be mostly
conjecture.

I note that the SSDs are only instance storage. The data will be gone when the
instance goes away. I have used instance storage in replicated setups but it
always feels rather fragile unless your data really is transient or you can
maintain 2 replicas.

Their other new service, provisioned IOPS for EBS, might be more useful for a
persistent database. Although not nearly SSD speeds, of course.

#15Vincent Veyron
vv.lists@wanadoo.fr
In reply to: Sébastien Lorion (#12)
Re: Amazon High I/O instances

Le mercredi 22 aoᅵt 2012 ᅵ 13:30 -0400, Sᅵbastien Lorion a ᅵcrit :

Vincent, I would appreciate that you stop assuming things based on
zero information about what I am doing. I understand that you are
trying to be helpful, but I can assure you that going bare-metal only
does not make any sense in my context.

Dude,

I would appreciate you realize that approaching a newsgroup while
providing zero information about what you are doing (in your own words)
is not the best way to get relevant responses to your question.

Ignoring repeated requests for information does not help, castigating
people trying to help for not having said information at least shows a
certain consistency on your part.

Lest we ridicule ourselves publicly, I suggest we leave the discussion
at that and wish you luck in your endeavor.

Vincent Veyron

#16Anthony
osm@inbox.org
In reply to: Vincent Veyron (#15)
Re: Amazon High I/O instances

On Thu, Aug 23, 2012 at 7:39 AM, Vincent Veyron <vv.lists@wanadoo.fr> wrote:

Lest we ridicule ourselves publicly, I suggest we leave the discussion
at that and wish you luck in your endeavor.

If anyone has an answer to his question, I'd appreciate hearing it,
despite any faux pas that the OP has committed.

#17Sébastien Lorion
sl@thestrangefactory.com
In reply to: Vincent Veyron (#15)
Re: Amazon High I/O instances

Vincent,

The original question can be summed up by "how is general performance of
PostgreSQL on Amazon IOPS". I fail to understand why that would require me
to explain the specifics of my application and/or my market. The only one
asking for that information is you, while others have provided useful
answers, for which I am very grateful.

p.s. My name is not "dude" or "seb", we have not raised the pigs together
...

Sébastien

On Thu, Aug 23, 2012 at 7:39 AM, Vincent Veyron <vv.lists@wanadoo.fr> wrote:

Show quoted text

Le mercredi 22 août 2012 à 13:30 -0400, Sébastien Lorion a écrit :

Vincent, I would appreciate that you stop assuming things based on
zero information about what I am doing. I understand that you are
trying to be helpful, but I can assure you that going bare-metal only
does not make any sense in my context.

Dude,

I would appreciate you realize that approaching a newsgroup while
providing zero information about what you are doing (in your own words)
is not the best way to get relevant responses to your question.

Ignoring repeated requests for information does not help, castigating
people trying to help for not having said information at least shows a
certain consistency on your part.

Lest we ridicule ourselves publicly, I suggest we leave the discussion
at that and wish you luck in your endeavor.

Vincent Veyron

#18Craig Ringer
craig@2ndquadrant.com
In reply to: Vincent Veyron (#15)
Re: Amazon High I/O instances

On 08/23/2012 07:39 PM, Vincent Veyron wrote:

Le mercredi 22 aoᅵt 2012 ᅵ 13:30 -0400, Sᅵbastien Lorion a ᅵcrit :

Vincent, I would appreciate that you stop assuming things based on
zero information about what I am doing. I understand that you are
trying to be helpful, but I can assure you that going bare-metal only
does not make any sense in my context.

Dude,

I would appreciate you realize that approaching a newsgroup while
providing zero information about what you are doing

In this case, what he's doing is seeking generalized performance
measurements. I don't think details were particularly necessary until it
got pulled off-track.

I'll be interested to hear if you have any results Sᅵbastien, or if
anyone else does. It's good to have data on the increasingly popular
cloud platforms out there.

--
Craig Ringer

#19Merlin Moncure
mmoncure@gmail.com
In reply to: Alan Hodgson (#14)
Re: Amazon High I/O instances

On Wed, Aug 22, 2012 at 4:12 PM, Alan Hodgson <ahodgson@simkin.ca> wrote:

On Wednesday, August 22, 2012 04:10:01 PM Andrew Hannon wrote:

Just looking into High IO instances for a DB deployment. In order to get
past 1TB, we are looking at RAID-0. I have heard
(http://hackerne.ws/item?id=4266119) there might be a problem if TRIM isn't
supported. Does anyone know if it is and has anyone used RAID-0 on these
instances? (Linux of course…)

Just use LVM striping. If it turns out to be an issue; that seems to be mostly
conjecture.

I note that the SSDs are only instance storage. The data will be gone when the
instance goes away. I have used instance storage in replicated setups but it
always feels rather fragile unless your data really is transient or you can
maintain 2 replicas.

Their other new service, provisioned IOPS for EBS, might be more useful for a
persistent database. Although not nearly SSD speeds, of course.

Yeah -- I should have mentioned that: you absolutely must run hs/sr or
some other strategy that maintains your data. I guess you might as
well turn off fsync, right?

merlin

#20John R Pierce
pierce@hogranch.com
In reply to: Craig Ringer (#18)
Re: Amazon High I/O instances

On 08/23/12 6:49 AM, Craig Ringer wrote:

In this case, what he's doing is seeking generalized performance
measurements. I don't think details were particularly necessary until
it got pulled off-track.

"42"

performance measurements without a very narrow definition of
'performance' are useless. depending on the nature of the application
workload, postgres can stress completely different aspects of the system
(cpu vs read IO performance vs write IO performance being the big three).

--
john r pierce N 37, W 122
santa cruz ca mid-left coast

#21Sébastien Lorion
sl@thestrangefactory.com
In reply to: John R Pierce (#20)
#22John R Pierce
pierce@hogranch.com
In reply to: Sébastien Lorion (#21)
#23Sébastien Lorion
sl@thestrangefactory.com
In reply to: John R Pierce (#22)
#24Sébastien Lorion
sl@thestrangefactory.com
In reply to: John R Pierce (#22)
#25François Beausoleil
francois@teksol.info
In reply to: Sébastien Lorion (#24)
#26John R Pierce
pierce@hogranch.com
In reply to: François Beausoleil (#25)
#27Sébastien Lorion
sl@thestrangefactory.com
In reply to: François Beausoleil (#25)
#28John R Pierce
pierce@hogranch.com
In reply to: Sébastien Lorion (#27)
#29Sébastien Lorion
sl@thestrangefactory.com
In reply to: John R Pierce (#28)
#30John R Pierce
pierce@hogranch.com
In reply to: Sébastien Lorion (#29)
#31Sébastien Lorion
sl@thestrangefactory.com
In reply to: John R Pierce (#28)
#32Sébastien Lorion
sl@thestrangefactory.com
In reply to: John R Pierce (#30)
#33Sébastien Lorion
sl@thestrangefactory.com
In reply to: Sébastien Lorion (#32)
#34Sébastien Lorion
sl@thestrangefactory.com
In reply to: Sébastien Lorion (#33)
#35Sébastien Lorion
sl@thestrangefactory.com
In reply to: Sébastien Lorion (#34)
#36Sébastien Lorion
sl@thestrangefactory.com
In reply to: Sébastien Lorion (#35)
#37Chris Travers
chris.travers@gmail.com
In reply to: Vincent Veyron (#3)
#38Sébastien Lorion
sl@thestrangefactory.com
In reply to: Sébastien Lorion (#35)
#39John R Pierce
pierce@hogranch.com
In reply to: Sébastien Lorion (#38)
#40Sébastien Lorion
sl@thestrangefactory.com
In reply to: John R Pierce (#39)
#41Sébastien Lorion
sl@thestrangefactory.com
In reply to: John R Pierce (#39)
#42John R Pierce
pierce@hogranch.com
In reply to: Sébastien Lorion (#41)
#43Sébastien Lorion
sl@thestrangefactory.com
In reply to: John R Pierce (#42)
#44Sébastien Lorion
sl@thestrangefactory.com
In reply to: Chris Travers (#37)