Menu
▾
▴
iometer-devel — Dedicated for people who are contributing to the project / are interested in.
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(17) |
Mar
(26) |
Apr
(3) |
May
(20) |
Jun
(3) |
Jul
(22) |
Aug
(15) |
Sep
(3) |
Oct
(12) |
Nov
(1) |
Dec
(6) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(4) |
Feb
(11) |
Mar
(14) |
Apr
(48) |
May
(14) |
Jun
(24) |
Jul
(38) |
Aug
(17) |
Sep
(29) |
Oct
(13) |
Nov
(19) |
Dec
(21) |
| 2005 |
Jan
(16) |
Feb
(14) |
Mar
(23) |
Apr
(36) |
May
(15) |
Jun
(13) |
Jul
(39) |
Aug
(29) |
Sep
(5) |
Oct
(2) |
Nov
(13) |
Dec
(8) |
| 2006 |
Jan
(6) |
Feb
(12) |
Mar
(8) |
Apr
(34) |
May
(8) |
Jun
(36) |
Jul
(8) |
Aug
(22) |
Sep
(16) |
Oct
(54) |
Nov
(33) |
Dec
(16) |
| 2007 |
Jan
(8) |
Feb
(18) |
Mar
(6) |
Apr
|
May
(1) |
Jun
(12) |
Jul
(2) |
Aug
(10) |
Sep
(31) |
Oct
(1) |
Nov
(5) |
Dec
(3) |
| 2008 |
Jan
(3) |
Feb
(6) |
Mar
(33) |
Apr
(21) |
May
|
Jun
(8) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(13) |
Nov
(2) |
Dec
(4) |
| 2009 |
Jan
(3) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
(2) |
Jun
(1) |
Jul
|
Aug
(12) |
Sep
(4) |
Oct
|
Nov
(4) |
Dec
(2) |
| 2011 |
Jan
(11) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(5) |
Aug
(3) |
Sep
(9) |
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
(19) |
Mar
(7) |
Apr
(2) |
May
(7) |
Jun
|
Jul
(3) |
Aug
|
Sep
(2) |
Oct
(1) |
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2014 |
Jan
(21) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(2) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
(1) |
Mar
(3) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(3) |
Nov
|
Dec
(1) |
| 2025 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Jeff S. <jsq...@ci...> - 2011-07-13 19:47:08
|
Just a friendly note: the links to the mailing list archives on this web page are incorrect:
http://iometer.org/doc/mailinglists.html
--
Jeff Squyres
jsq...@ci...
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
|
|
From: SourceForge.net <no...@so...> - 2011-04-20 07:15:00
|
Bugs item #3290151, was opened at 2011-04-20 15:15 Message generated for change (Tracker Item Submitted) made by zomin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=427254&aid=3290151&group_id=40179 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Zomin (zomin) Assigned to: Nobody/Anonymous (nobody) Summary: will show read/write error for all SSD using my script Initial Comment: when I use my script to test the SSD , after several hours, the iometer will report read and write errors. I have tried sevral types of SSD, all have the same issue. But the HDD is OK. This issue can easier reproduced use my script. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=427254&aid=3290151&group_id=40179 |
|
From: Vedran D. <ve...@ya...> - 2011-01-07 00:59:09
|
I am ok either way, so I will defer to the consensus of the group. Ved ________________________________ From: Daniel Scheibli <da...@sc...> To: Vedran Degoricija <ve...@ya...> Cc: ming zhang <mi...@el...>; "iom...@li..." <iom...@li...>; "ssh...@sa..." <ssh...@sa...> Sent: Thu, January 6, 2011 3:37:28 PM Subject: Re: [Iometer-devel] SVN branch strategy (wss Re: SandForce IOMeter integration) Hi Ved, well we just got bit with the last experience of branching & merging and that wasn't even a hard case. So why go there again without even having a strong need for doing it? Also following your assumption of work being serial, I don't see why you then would want to merge. There would be no point in it - unless you are experimenting and unsure if your branch might reach a dead end. Most of those cases IMHO are already served by your local working directory. Daniel Vedran Degoricija wrote: > Daniel, > > I'd agree about SVN merges, but at the rate we are going, it should not > hurt to branch it, particularly if we do not change the trunk or fork > another branch. To date, we have branched but always (mostly) serialized > the work. Also, I don't mind merging any two branches that have deviated > if it becomes necessary. It does not take very long even with 2 separate > branches, as the changes usually span different files. > > Ved > > > ------------------------------------------------------------------------ > *From:* Daniel Scheibli <da...@sc...> > *To:* ming zhang <mi...@el...> > *Cc:* "iom...@li..." > <iom...@li...>; "ssh...@sa..." > <ssh...@sa...> > *Sent:* Thu, January 6, 2011 9:55:24 AM > *Subject:* [Iometer-devel] SVN branch strategy (wss Re: SandForce > IOMeter integration) > > > Hi all, > > as we (mainly Ved and I) just happened to have discussed the > branch strategy lately, I would like to emphasize that trunk is > always the latest & greatest / leading code base. > > Once 1.1.0 is released, we will branch it so bug fixes for the > 1.1.N revisions can go in there. The mainline, so the upcoming > versions like 1.2.0 etc. will continue to be developed in trunk. > > Also for new developments, branches should be avoided where > possible. Merging branches in SVN is a pain. Especially if > branches happen to develop over some time it gets ugly. > > So IMHO it is better to aim for bringing in your changes in > digestible pieces to trunk directly. > > Daniel > > > > ming zhang wrote: >> agree. a branch for this is better. >> >> >> On Wed, Jan 5, 2011 at 8:02 PM, Allen, Wayne <way...@in... > <mailto:way...@in...>> wrote: >>> Re-sending....ssh...@us... > <mailto:Re-sending....ssh...@us...> bounced. >>> >>> -Wayne >>> >>> -----Original Message----- >>> From: Allen, Wayne >>> Sent: Wednesday, January 05, 2011 5:00 PM >>> To: 'ssh...@us... > <mailto:ssh...@us...>'; > iom...@li... > <mailto:iom...@li...> >>> Subject: RE: SandForce IOMeter integration >>> >>> Hi Shamil, >>> >>> Yes, we had an email exchange with Ben toward the middle part of last > year regarding some changes (though he described them a bit different > than you). We communicated to him that we were working on finalizing a > release and would be able to get to it after that. Our release didn't > end up happening (due to all of our actual day jobs) till November. We > are currently in a release-candidate state with that release, so the > work isn't completely done yet. What I'd propose we do here (haven't run > past the other admins) is that we create a branch for the features for > our next release and can get your stuff in there. This also makes it > available to folks across the industry if they want to pull source out > of SVN and build it on their own prior to us releasing an official > build. I'll let the other admins chime in if they have concerns with that. >>> >>> Could you explain your feature a bit more? Have you merged it with > the latest trunk code in SVN? If not, that would be a good place to > start for getting it checked in. >>> >>> Thanks, >>> >>> Wayne >>> >>> -----Original Message----- >>> From: ssh...@us... > <mailto:ssh...@us...> > [mailto:ssh...@us... > <mailto:ssh...@us...>] >>> Sent: Wednesday, January 05, 2011 4:25 PM >>> To: al...@us... <mailto:al...@us...> >>> Cc: ssh...@us... > <mailto:ssh...@us...> >>> Subject: SandForce IOMeter integration >>> >>> Hi, >>> >>> My name is Shamil Sharief, the Technical Marketing >>> Specialist here at SandForce Inc. I believe one of my former >>> colleagues, Ben Englert, was in contact with the developers >>> of IOMeter, and I wanted to let you guys know that his torch >>> has been passed to me as of a bit ago. >>> >>> >From what I understand, the current status of SandForce's >>> input is at a non-existent phase. I was wondering if it >>> would be possible for me to work with you and whoever else I >>> need to be in touch with regarding incorporating our changes in. >>> >>> To recap, the change we've added is the ability to select >>> what file the tool uses as its data pattern. If it would be >>> possible for me to send you a copy of our source code, I >>> would appreciate it greatly. >>> >>> I've sent an identical message to Daniel Scheibli. If >>> someone could get back to me regarding this process needed >>> to get this going, it'd be great. Alternatively, maybe get >>> me in touch with who can help me with this? >>> >>> Thanks for all your help, >>> ~Shamil Sharief >>> >>> Technical Marketing Specialist >>> Direct: 408-864-0740 >>> Cell: 408-410-9527 >>> email: ssh...@sa... <mailto:ssh...@sa...> >>> >>> -- >>> This message has been sent to you, a registered SourceForge.net > <http://sourceforge.net/> user, >>> by another site user, through the SourceForge.net site. This message >>> has been delivered to your SourceForge.net mail alias. You may reply >>> to this message using the "Reply" feature of your email client, or >>> using the messaging facility of SourceForge.net at: >>> https://sourceforge.net/sendmessage.php?touser=3187781 >>> >>> > ------------------------------------------------------------------------------ >>> Learn how Oracle Real Application Clusters (RAC) One Node allows > customers >>> to consolidate database storage, standardize their database > environment, and, >>> should the need arise, upgrade to a full multi-node Oracle RAC database >>> without downtime or disruption >>> http://p.sf.net/sfu/oracle-sfdevnl >>> _______________________________________________ >>> Iometer-devel mailing list >>> Iom...@li... > <mailto:Iom...@li...> >>> https://lists.sourceforge.net/lists/listinfo/iometer-devel >>> >> >> > ------------------------------------------------------------------------------ >> Learn how Oracle Real Application Clusters (RAC) One Node allows customers >> to consolidate database storage, standardize their database > environment, and, >> should the need arise, upgrade to a full multi-node Oracle RAC database >> without downtime or disruption >> http://p.sf.net/sfu/oracle-sfdevnl >> _______________________________________________ >> Iometer-devel mailing list >> Iom...@li... > <mailto:Iom...@li...> >> https://lists.sourceforge.net/lists/listinfo/iometer-devel >> > > > ------------------------------------------------------------------------------ > Learn how Oracle Real Application Clusters (RAC) One Node allows customers > to consolidate database storage, standardize their database environment, > and, > should the need arise, upgrade to a full multi-node Oracle RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Iometer-devel mailing list > Iom...@li... > <mailto:Iom...@li...> > https://lists.sourceforge.net/lists/listinfo/iometer-devel > |
|
From: Daniel S. <da...@sc...> - 2011-01-06 23:37:14
|
Hi Ved, well we just got bit with the last experience of branching & merging and that wasn't even a hard case. So why go there again without even having a strong need for doing it? Also following your assumption of work being serial, I don't see why you then would want to merge. There would be no point in it - unless you are experimenting and unsure if your branch might reach a dead end. Most of those cases IMHO are already served by your local working directory. Daniel Vedran Degoricija wrote: > Daniel, > > I'd agree about SVN merges, but at the rate we are going, it should not > hurt to branch it, particularly if we do not change the trunk or fork > another branch. To date, we have branched but always (mostly) serialized > the work. Also, I don't mind merging any two branches that have deviated > if it becomes necessary. It does not take very long even with 2 separate > branches, as the changes usually span different files. > > Ved > > > ------------------------------------------------------------------------ > *From:* Daniel Scheibli <da...@sc...> > *To:* ming zhang <mi...@el...> > *Cc:* "iom...@li..." > <iom...@li...>; "ssh...@sa..." > <ssh...@sa...> > *Sent:* Thu, January 6, 2011 9:55:24 AM > *Subject:* [Iometer-devel] SVN branch strategy (wss Re: SandForce > IOMeter integration) > > > Hi all, > > as we (mainly Ved and I) just happened to have discussed the > branch strategy lately, I would like to emphasize that trunk is > always the latest & greatest / leading code base. > > Once 1.1.0 is released, we will branch it so bug fixes for the > 1.1.N revisions can go in there. The mainline, so the upcoming > versions like 1.2.0 etc. will continue to be developed in trunk. > > Also for new developments, branches should be avoided where > possible. Merging branches in SVN is a pain. Especially if > branches happen to develop over some time it gets ugly. > > So IMHO it is better to aim for bringing in your changes in > digestible pieces to trunk directly. > > Daniel > > > > ming zhang wrote: >> agree. a branch for this is better. >> >> >> On Wed, Jan 5, 2011 at 8:02 PM, Allen, Wayne <way...@in... > <mailto:way...@in...>> wrote: >>> Re-sending....ssh...@us... > <mailto:Re-sending....ssh...@us...> bounced. >>> >>> -Wayne >>> >>> -----Original Message----- >>> From: Allen, Wayne >>> Sent: Wednesday, January 05, 2011 5:00 PM >>> To: 'ssh...@us... > <mailto:ssh...@us...>'; > iom...@li... > <mailto:iom...@li...> >>> Subject: RE: SandForce IOMeter integration >>> >>> Hi Shamil, >>> >>> Yes, we had an email exchange with Ben toward the middle part of last > year regarding some changes (though he described them a bit different > than you). We communicated to him that we were working on finalizing a > release and would be able to get to it after that. Our release didn't > end up happening (due to all of our actual day jobs) till November. We > are currently in a release-candidate state with that release, so the > work isn't completely done yet. What I'd propose we do here (haven't run > past the other admins) is that we create a branch for the features for > our next release and can get your stuff in there. This also makes it > available to folks across the industry if they want to pull source out > of SVN and build it on their own prior to us releasing an official > build. I'll let the other admins chime in if they have concerns with that. >>> >>> Could you explain your feature a bit more? Have you merged it with > the latest trunk code in SVN? If not, that would be a good place to > start for getting it checked in. >>> >>> Thanks, >>> >>> Wayne >>> >>> -----Original Message----- >>> From: ssh...@us... > <mailto:ssh...@us...> > [mailto:ssh...@us... > <mailto:ssh...@us...>] >>> Sent: Wednesday, January 05, 2011 4:25 PM >>> To: al...@us... <mailto:al...@us...> >>> Cc: ssh...@us... > <mailto:ssh...@us...> >>> Subject: SandForce IOMeter integration >>> >>> Hi, >>> >>> My name is Shamil Sharief, the Technical Marketing >>> Specialist here at SandForce Inc. I believe one of my former >>> colleagues, Ben Englert, was in contact with the developers >>> of IOMeter, and I wanted to let you guys know that his torch >>> has been passed to me as of a bit ago. >>> >>> >From what I understand, the current status of SandForce's >>> input is at a non-existent phase. I was wondering if it >>> would be possible for me to work with you and whoever else I >>> need to be in touch with regarding incorporating our changes in. >>> >>> To recap, the change we've added is the ability to select >>> what file the tool uses as its data pattern. If it would be >>> possible for me to send you a copy of our source code, I >>> would appreciate it greatly. >>> >>> I've sent an identical message to Daniel Scheibli. If >>> someone could get back to me regarding this process needed >>> to get this going, it'd be great. Alternatively, maybe get >>> me in touch with who can help me with this? >>> >>> Thanks for all your help, >>> ~Shamil Sharief >>> >>> Technical Marketing Specialist >>> Direct: 408-864-0740 >>> Cell: 408-410-9527 >>> email: ssh...@sa... <mailto:ssh...@sa...> >>> >>> -- >>> This message has been sent to you, a registered SourceForge.net > <http://sourceforge.net/> user, >>> by another site user, through the SourceForge.net site. This message >>> has been delivered to your SourceForge.net mail alias. You may reply >>> to this message using the "Reply" feature of your email client, or >>> using the messaging facility of SourceForge.net at: >>> https://sourceforge.net/sendmessage.php?touser=3187781 >>> >>> > ------------------------------------------------------------------------------ >>> Learn how Oracle Real Application Clusters (RAC) One Node allows > customers >>> to consolidate database storage, standardize their database > environment, and, >>> should the need arise, upgrade to a full multi-node Oracle RAC database >>> without downtime or disruption >>> http://p.sf.net/sfu/oracle-sfdevnl >>> _______________________________________________ >>> Iometer-devel mailing list >>> Iom...@li... > <mailto:Iom...@li...> >>> https://lists.sourceforge.net/lists/listinfo/iometer-devel >>> >> >> > ------------------------------------------------------------------------------ >> Learn how Oracle Real Application Clusters (RAC) One Node allows customers >> to consolidate database storage, standardize their database > environment, and, >> should the need arise, upgrade to a full multi-node Oracle RAC database >> without downtime or disruption >> http://p.sf.net/sfu/oracle-sfdevnl >> _______________________________________________ >> Iometer-devel mailing list >> Iom...@li... > <mailto:Iom...@li...> >> https://lists.sourceforge.net/lists/listinfo/iometer-devel >> > > > ------------------------------------------------------------------------------ > Learn how Oracle Real Application Clusters (RAC) One Node allows customers > to consolidate database storage, standardize their database environment, > and, > should the need arise, upgrade to a full multi-node Oracle RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Iometer-devel mailing list > Iom...@li... > <mailto:Iom...@li...> > https://lists.sourceforge.net/lists/listinfo/iometer-devel > |
|
From: Vedran D. <ve...@ya...> - 2011-01-06 19:23:19
|
Daniel, I'd agree about SVN merges, but at the rate we are going, it should not hurt to branch it, particularly if we do not change the trunk or fork another branch. To date, we have branched but always (mostly) serialized the work. Also, I don't mind merging any two branches that have deviated if it becomes necessary. It does not take very long even with 2 separate branches, as the changes usually span different files. Ved ________________________________ From: Daniel Scheibli <da...@sc...> To: ming zhang <mi...@el...> Cc: "iom...@li..." <iom...@li...>; "ssh...@sa..." <ssh...@sa...> Sent: Thu, January 6, 2011 9:55:24 AM Subject: [Iometer-devel] SVN branch strategy (wss Re: SandForce IOMeter integration) Hi all, as we (mainly Ved and I) just happened to have discussed the branch strategy lately, I would like to emphasize that trunk is always the latest & greatest / leading code base. Once 1.1.0 is released, we will branch it so bug fixes for the 1.1.N revisions can go in there. The mainline, so the upcoming versions like 1.2.0 etc. will continue to be developed in trunk. Also for new developments, branches should be avoided where possible. Merging branches in SVN is a pain. Especially if branches happen to develop over some time it gets ugly. So IMHO it is better to aim for bringing in your changes in digestible pieces to trunk directly. Daniel ming zhang wrote: > agree. a branch for this is better. > > > On Wed, Jan 5, 2011 at 8:02 PM, Allen, Wayne <way...@in...> wrote: >> Re-sending....ssh...@us... bounced. >> >> -Wayne >> >> -----Original Message----- >> From: Allen, Wayne >> Sent: Wednesday, January 05, 2011 5:00 PM >> To: 'ssh...@us...'; iom...@li... >> Subject: RE: SandForce IOMeter integration >> >> Hi Shamil, >> >> Yes, we had an email exchange with Ben toward the middle part of last year >>regarding some changes (though he described them a bit different than you). We >>communicated to him that we were working on finalizing a release and would be >>able to get to it after that. Our release didn't end up happening (due to all of >>our actual day jobs) till November. We are currently in a release-candidate >>state with that release, so the work isn't completely done yet. What I'd propose >>we do here (haven't run past the other admins) is that we create a branch for >>the features for our next release and can get your stuff in there. This also >>makes it available to folks across the industry if they want to pull source out >>of SVN and build it on their own prior to us releasing an official build. I'll >>let the other admins chime in if they have concerns with that. >> >> Could you explain your feature a bit more? Have you merged it with the latest >>trunk code in SVN? If not, that would be a good place to start for getting it >>checked in. >> >> Thanks, >> >> Wayne >> >> -----Original Message----- >> From: ssh...@us... [mailto:ssh...@us...] >> Sent: Wednesday, January 05, 2011 4:25 PM >> To: al...@us... >> Cc: ssh...@us... >> Subject: SandForce IOMeter integration >> >> Hi, >> >> My name is Shamil Sharief, the Technical Marketing >> Specialist here at SandForce Inc. I believe one of my former >> colleagues, Ben Englert, was in contact with the developers >> of IOMeter, and I wanted to let you guys know that his torch >> has been passed to me as of a bit ago. >> >> >From what I understand, the current status of SandForce's >> input is at a non-existent phase. I was wondering if it >> would be possible for me to work with you and whoever else I >> need to be in touch with regarding incorporating our changes in. >> >> To recap, the change we've added is the ability to select >> what file the tool uses as its data pattern. If it would be >> possible for me to send you a copy of our source code, I >> would appreciate it greatly. >> >> I've sent an identical message to Daniel Scheibli. If >> someone could get back to me regarding this process needed >> to get this going, it'd be great. Alternatively, maybe get >> me in touch with who can help me with this? >> >> Thanks for all your help, >> ~Shamil Sharief >> >> Technical Marketing Specialist >> Direct: 408-864-0740 >> Cell: 408-410-9527 >> email: ssh...@sa... >> >> -- >> This message has been sent to you, a registered SourceForge.net user, >> by another site user, through the SourceForge.net site. This message >> has been delivered to your SourceForge.net mail alias. You may reply >> to this message using the "Reply" feature of your email client, or >> using the messaging facility of SourceForge.net at: >> https://sourceforge.net/sendmessage.php?touser=3187781 >> >> ------------------------------------------------------------------------------ >> Learn how Oracle Real Application Clusters (RAC) One Node allows customers >> to consolidate database storage, standardize their database environment, and, >> should the need arise, upgrade to a full multi-node Oracle RAC database >> without downtime or disruption >> http://p.sf.net/sfu/oracle-sfdevnl >> _______________________________________________ >> Iometer-devel mailing list >> Iom...@li... >> https://lists.sourceforge.net/lists/listinfo/iometer-devel >> > > ------------------------------------------------------------------------------ > Learn how Oracle Real Application Clusters (RAC) One Node allows customers > to consolidate database storage, standardize their database environment, and, > should the need arise, upgrade to a full multi-node Oracle RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Iometer-devel mailing list > Iom...@li... > https://lists.sourceforge.net/lists/listinfo/iometer-devel > ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Iometer-devel mailing list Iom...@li... https://lists.sourceforge.net/lists/listinfo/iometer-devel |
|
From: Daniel S. <da...@sc...> - 2011-01-06 18:14:29
|
Hi all, as we (mainly Ved and I) just happened to have discussed the branch strategy lately, I would like to emphasize that trunk is always the latest & greatest / leading code base. Once 1.1.0 is released, we will branch it so bug fixes for the 1.1.N revisions can go in there. The mainline, so the upcoming versions like 1.2.0 etc. will continue to be developed in trunk. Also for new developments, branches should be avoided where possible. Merging branches in SVN is a pain. Especially if branches happen to develop over some time it gets ugly. So IMHO it is better to aim for bringing in your changes in digestible pieces to trunk directly. Daniel ming zhang wrote: > agree. a branch for this is better. > > > On Wed, Jan 5, 2011 at 8:02 PM, Allen, Wayne <way...@in...> wrote: >> Re-sending....ssh...@us... bounced. >> >> -Wayne >> >> -----Original Message----- >> From: Allen, Wayne >> Sent: Wednesday, January 05, 2011 5:00 PM >> To: 'ssh...@us...'; iom...@li... >> Subject: RE: SandForce IOMeter integration >> >> Hi Shamil, >> >> Yes, we had an email exchange with Ben toward the middle part of last year regarding some changes (though he described them a bit different than you). We communicated to him that we were working on finalizing a release and would be able to get to it after that. Our release didn't end up happening (due to all of our actual day jobs) till November. We are currently in a release-candidate state with that release, so the work isn't completely done yet. What I'd propose we do here (haven't run past the other admins) is that we create a branch for the features for our next release and can get your stuff in there. This also makes it available to folks across the industry if they want to pull source out of SVN and build it on their own prior to us releasing an official build. I'll let the other admins chime in if they have concerns with that. >> >> Could you explain your feature a bit more? Have you merged it with the latest trunk code in SVN? If not, that would be a good place to start for getting it checked in. >> >> Thanks, >> >> Wayne >> >> -----Original Message----- >> From: ssh...@us... [mailto:ssh...@us...] >> Sent: Wednesday, January 05, 2011 4:25 PM >> To: al...@us... >> Cc: ssh...@us... >> Subject: SandForce IOMeter integration >> >> Hi, >> >> My name is Shamil Sharief, the Technical Marketing >> Specialist here at SandForce Inc. I believe one of my former >> colleagues, Ben Englert, was in contact with the developers >> of IOMeter, and I wanted to let you guys know that his torch >> has been passed to me as of a bit ago. >> >> >From what I understand, the current status of SandForce's >> input is at a non-existent phase. I was wondering if it >> would be possible for me to work with you and whoever else I >> need to be in touch with regarding incorporating our changes in. >> >> To recap, the change we've added is the ability to select >> what file the tool uses as its data pattern. If it would be >> possible for me to send you a copy of our source code, I >> would appreciate it greatly. >> >> I've sent an identical message to Daniel Scheibli. If >> someone could get back to me regarding this process needed >> to get this going, it'd be great. Alternatively, maybe get >> me in touch with who can help me with this? >> >> Thanks for all your help, >> ~Shamil Sharief >> >> Technical Marketing Specialist >> Direct: 408-864-0740 >> Cell: 408-410-9527 >> email: ssh...@sa... >> >> -- >> This message has been sent to you, a registered SourceForge.net user, >> by another site user, through the SourceForge.net site. This message >> has been delivered to your SourceForge.net mail alias. You may reply >> to this message using the "Reply" feature of your email client, or >> using the messaging facility of SourceForge.net at: >> https://sourceforge.net/sendmessage.php?touser=3187781 >> >> ------------------------------------------------------------------------------ >> Learn how Oracle Real Application Clusters (RAC) One Node allows customers >> to consolidate database storage, standardize their database environment, and, >> should the need arise, upgrade to a full multi-node Oracle RAC database >> without downtime or disruption >> http://p.sf.net/sfu/oracle-sfdevnl >> _______________________________________________ >> Iometer-devel mailing list >> Iom...@li... >> https://lists.sourceforge.net/lists/listinfo/iometer-devel >> > > ------------------------------------------------------------------------------ > Learn how Oracle Real Application Clusters (RAC) One Node allows customers > to consolidate database storage, standardize their database environment, and, > should the need arise, upgrade to a full multi-node Oracle RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Iometer-devel mailing list > Iom...@li... > https://lists.sourceforge.net/lists/listinfo/iometer-devel > |
|
From: <jo...@ei...> - 2011-01-06 06:40:03
|
Or add it as an attachment to the patch tracker on sourceforge if you don't have another option. Quoting "Allen, Wayne" <way...@in...>: > Hi Shamil, > > Our email system only allows for attachments under 5MB. Do you have > a place we could download it from? > > Thanks, > > Wayne > > From: Shamil Sharief [mailto:ssh...@sa...] > Sent: Wednesday, January 05, 2011 6:03 PM > To: Allen, Wayne; iom...@li... > Cc: Kent Smith > Subject: RE: SandForce IOMeter integration > > > Hi Wayne, > > > > Thank you for the quick reply. > > > > I?ve attached a copy of a readme file (in PDF format) that explains > the extra feature that was implemented. Please take a look at it and > let me know if you have any questions. If possible, I?d also like to > send you a windows binary version of the tool with said feature > implemented, so that you can test it out yourself. However, the zip > file is about 20mb in size. I wanted to ask before I send something > that big via email. > > > > Thanks, > > ~Shamil > > > Shamil Sharief > Technical Marketing Specialist > SandForce Inc. > phone: 408-864-0740 > email: ssh...@sa...<mailto:ssh...@sa...> > > > > -----Original Message----- > > From: Allen, Wayne > > Sent: Wednesday, January 05, 2011 5:00 PM > > To: 'ssh...@us...'; iom...@li... > > Subject: RE: SandForce IOMeter integration > > > > Hi Shamil, > > > > Yes, we had an email exchange with Ben toward the middle part of > last year regarding some changes (though he described them a bit > different than you). We communicated to him that we were working on > finalizing a release and would be able to get to it after that. Our > release didn't end up happening (due to all of our actual day jobs) > till November. We are currently in a release-candidate state with > that release, so the work isn't completely done yet. What I'd > propose we do here (haven't run past the other admins) is that we > create a branch for the features for our next release and can get > your stuff in there. This also makes it available to folks across > the industry if they want to pull source out of SVN and build it on > their own prior to us releasing an official build. I'll let the > other admins chime in if they have concerns with that. > > > > Could you explain your feature a bit more? Have you merged it with > the latest trunk code in SVN? If not, that would be a good place to > start for getting it checked in. > > > > Thanks, > > > > Wayne > > > > -----Original Message----- > > From: ssh...@us... [mailto:ssh...@us...] > > Sent: Wednesday, January 05, 2011 4:25 PM > > To: al...@us... > > Cc: ssh...@us... > > Subject: SandForce IOMeter integration > > > > Hi, > > > > My name is Shamil Sharief, the Technical Marketing Specialist here > at SandForce Inc. I believe one of my former colleagues, Ben > Englert, was in contact with the developers of IOMeter, and I wanted > to let you guys know that his torch has been passed to me as of a > bit ago. > > > > From what I understand, the current status of SandForce's input is > at a non-existent phase. I was wondering if it would be possible for > me to work with you and whoever else I need to be in touch with > regarding incorporating our changes in. > > > > To recap, the change we've added is the ability to select what file > the tool uses as its data pattern. If it would be possible for me to > send you a copy of our source code, I would appreciate it greatly. > > > > I've sent an identical message to Daniel Scheibli. If someone could > get back to me regarding this process needed to get this going, it'd > be great. Alternatively, maybe get me in touch with who can help me > with this? > > > > Thanks for all your help, > > ~Shamil Sharief > > > > Technical Marketing Specialist > > Direct: 408-864-0740 > > Cell: 408-410-9527 > > email: ssh...@sa... > > > > -- > > This message has been sent to you, a registered SourceForge.net > user, by another site user, through the SourceForge.net site. This > message has been delivered to your SourceForge.net mail alias. You > may reply to this message using the "Reply" feature of your email > client, or using the messaging facility of SourceForge.net at: > > https://sourceforge.net/sendmessage.php?touser=3187781 > > > |
|
From: Allen, W. <way...@in...> - 2011-01-06 05:17:31
|
Hi Shamil, Our email system only allows for attachments under 5MB. Do you have a place we could download it from? Thanks, Wayne From: Shamil Sharief [mailto:ssh...@sa...] Sent: Wednesday, January 05, 2011 6:03 PM To: Allen, Wayne; iom...@li... Cc: Kent Smith Subject: RE: SandForce IOMeter integration Hi Wayne, Thank you for the quick reply. I’ve attached a copy of a readme file (in PDF format) that explains the extra feature that was implemented. Please take a look at it and let me know if you have any questions. If possible, I’d also like to send you a windows binary version of the tool with said feature implemented, so that you can test it out yourself. However, the zip file is about 20mb in size. I wanted to ask before I send something that big via email. Thanks, ~Shamil Shamil Sharief Technical Marketing Specialist SandForce Inc. phone: 408-864-0740 email: ssh...@sa...<mailto:ssh...@sa...> -----Original Message----- From: Allen, Wayne Sent: Wednesday, January 05, 2011 5:00 PM To: 'ssh...@us...'; iom...@li... Subject: RE: SandForce IOMeter integration Hi Shamil, Yes, we had an email exchange with Ben toward the middle part of last year regarding some changes (though he described them a bit different than you). We communicated to him that we were working on finalizing a release and would be able to get to it after that. Our release didn't end up happening (due to all of our actual day jobs) till November. We are currently in a release-candidate state with that release, so the work isn't completely done yet. What I'd propose we do here (haven't run past the other admins) is that we create a branch for the features for our next release and can get your stuff in there. This also makes it available to folks across the industry if they want to pull source out of SVN and build it on their own prior to us releasing an official build. I'll let the other admins chime in if they have concerns with that. Could you explain your feature a bit more? Have you merged it with the latest trunk code in SVN? If not, that would be a good place to start for getting it checked in. Thanks, Wayne -----Original Message----- From: ssh...@us... [mailto:ssh...@us...] Sent: Wednesday, January 05, 2011 4:25 PM To: al...@us... Cc: ssh...@us... Subject: SandForce IOMeter integration Hi, My name is Shamil Sharief, the Technical Marketing Specialist here at SandForce Inc. I believe one of my former colleagues, Ben Englert, was in contact with the developers of IOMeter, and I wanted to let you guys know that his torch has been passed to me as of a bit ago. From what I understand, the current status of SandForce's input is at a non-existent phase. I was wondering if it would be possible for me to work with you and whoever else I need to be in touch with regarding incorporating our changes in. To recap, the change we've added is the ability to select what file the tool uses as its data pattern. If it would be possible for me to send you a copy of our source code, I would appreciate it greatly. I've sent an identical message to Daniel Scheibli. If someone could get back to me regarding this process needed to get this going, it'd be great. Alternatively, maybe get me in touch with who can help me with this? Thanks for all your help, ~Shamil Sharief Technical Marketing Specialist Direct: 408-864-0740 Cell: 408-410-9527 email: ssh...@sa... -- This message has been sent to you, a registered SourceForge.net user, by another site user, through the SourceForge.net site. This message has been delivered to your SourceForge.net mail alias. You may reply to this message using the "Reply" feature of your email client, or using the messaging facility of SourceForge.net at: https://sourceforge.net/sendmessage.php?touser=3187781 |
|
From: Allen, W. <way...@in...> - 2011-01-06 05:16:39
|
Ved, I agree that adding it to the existing combo box would be the best integration path. Shamil, is this something your team can do prior to submitting your code? From: Vedran Degoricija [mailto:ve...@ya...] Sent: Wednesday, January 05, 2011 8:51 PM To: ming zhang; Allen, Wayne Cc: iom...@li...; ssh...@sa... Subject: Re: [Iometer-devel] SandForce IOMeter integration I recall this was just a file used as a data pattern. Ideally, I would like to see that as an item in the random data gen pull down selector, so one you select custom file, it provides a dialog box (or similar) asking to provide a path and file name etc.. In another words, I'd prefer to have it fit in with what we have today without creating another knob if possible. Otherwise, I agree with the branch. Fire away. Regards, Ved ________________________________ From: ming zhang <mi...@el...> To: "Allen, Wayne" <way...@in...> Cc: "iom...@li..." <iom...@li...>; "ssh...@sa..." <ssh...@sa...> Sent: Wed, January 5, 2011 6:00:04 PM Subject: Re: [Iometer-devel] SandForce IOMeter integration agree. a branch for this is better. On Wed, Jan 5, 2011 at 8:02 PM, Allen, Wayne <way...@in...<mailto:way...@in...>> wrote: > Re-sending....ssh...@us...<mailto:Re-sending....ssh...@us...> bounced. > > -Wayne > > -----Original Message----- > From: Allen, Wayne > Sent: Wednesday, January 05, 2011 5:00 PM > To: 'ssh...@us...<mailto:ssh...@us...>'; iom...@li...<mailto:iom...@li...> > Subject: RE: SandForce IOMeter integration > > Hi Shamil, > > Yes, we had an email exchange with Ben toward the middle part of last year regarding some changes (though he described them a bit different than you). We communicated to him that we were working on finalizing a release and would be able to get to it after that. Our release didn't end up happening (due to all of our actual day jobs) till November. We are currently in a release-candidate state with that release, so the work isn't completely done yet. What I'd propose we do here (haven't run past the other admins) is that we create a branch for the features for our next release and can get your stuff in there. This also makes it available to folks across the industry if they want to pull source out of SVN and build it on their own prior to us releasing an official build. I'll let the other admins chime in if they have concerns with that. > > Could you explain your feature a bit more? Have you merged it with the latest trunk code in SVN? If not, that would be a good place to start for getting it checked in. > > Thanks, > > Wayne > > -----Original Message----- > From: ssh...@us...<mailto:ssh...@us...> [mailto:ssh...@us...<mailto:ssh...@us...>] > Sent: Wednesday, January 05, 2011 4:25 PM > To: al...@us...<mailto:al...@us...> > Cc: ssh...@us...<mailto:ssh...@us...> > Subject: SandForce IOMeter integration > > Hi, > > My name is Shamil Sharief, the Technical Marketing > Specialist here at SandForce Inc. I believe one of my former > colleagues, Ben Englert, was in contact with the developers > of IOMeter, and I wanted to let you guys know that his torch > has been passed to me as of a bit ago. > > >From what I understand, the current status of SandForce's > input is at a non-existent phase. I was wondering if it > would be possible for me to work with you and whoever else I > need to be in touch with regarding incorporating our changes in. > > To recap, the change we've added is the ability to select > what file the tool uses as its data pattern. If it would be > possible for me to send you a copy of our source code, I > would appreciate it greatly. > > I've sent an identical message to Daniel Scheibli. If > someone could get back to me regarding this process needed > to get this going, it'd be great. Alternatively, maybe get > me in touch with who can help me with this? > > Thanks for all your help, > ~Shamil Sharief > > Technical Marketing Specialist > Direct: 408-864-0740 > Cell: 408-410-9527 > email: ssh...@sa...<mailto:ssh...@sa...> > > -- > This message has been sent to you, a registered SourceForge.net<http://sourceforge.net/> user, > by another site user, through the SourceForge.net site. This message > has been delivered to your SourceForge.net mail alias. You may reply > to this message using the "Reply" feature of your email client, or > using the messaging facility of SourceForge.net at: > https://sourceforge.net/sendmessage.php?touser=3187781 > > ------------------------------------------------------------------------------ > Learn how Oracle Real Application Clusters (RAC) One Node allows customers > to consolidate database storage, standardize their database environment, and, > should the need arise, upgrade to a full multi-node Oracle RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Iometer-devel mailing list > Iom...@li...<mailto:Iom...@li...> > https://lists.sourceforge.net/lists/listinfo/iometer-devel > ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Iometer-devel mailing list Iom...@li...<mailto:Iom...@li...> https://lists.sourceforge.net/lists/listinfo/iometer-devel |
|
From: Vedran D. <ve...@ya...> - 2011-01-06 04:51:04
|
I recall this was just a file used as a data pattern. Ideally, I would like to see that as an item in the random data gen pull down selector, so one you select custom file, it provides a dialog box (or similar) asking to provide a path and file name etc.. In another words, I'd prefer to have it fit in with what we have today without creating another knob if possible. Otherwise, I agree with the branch. Fire away. Regards, Ved ________________________________ From: ming zhang <mi...@el...> To: "Allen, Wayne" <way...@in...> Cc: "iom...@li..." <iom...@li...>; "ssh...@sa..." <ssh...@sa...> Sent: Wed, January 5, 2011 6:00:04 PM Subject: Re: [Iometer-devel] SandForce IOMeter integration agree. a branch for this is better. On Wed, Jan 5, 2011 at 8:02 PM, Allen, Wayne <way...@in...> wrote: > Re-sending....ssh...@us... bounced. > > -Wayne > > -----Original Message----- > From: Allen, Wayne > Sent: Wednesday, January 05, 2011 5:00 PM > To: 'ssh...@us...'; iom...@li... > Subject: RE: SandForce IOMeter integration > > Hi Shamil, > > Yes, we had an email exchange with Ben toward the middle part of last year >regarding some changes (though he described them a bit different than you). We >communicated to him that we were working on finalizing a release and would be >able to get to it after that. Our release didn't end up happening (due to all of >our actual day jobs) till November. We are currently in a release-candidate >state with that release, so the work isn't completely done yet. What I'd propose >we do here (haven't run past the other admins) is that we create a branch for >the features for our next release and can get your stuff in there. This also >makes it available to folks across the industry if they want to pull source out >of SVN and build it on their own prior to us releasing an official build. I'll >let the other admins chime in if they have concerns with that. > > Could you explain your feature a bit more? Have you merged it with the latest >trunk code in SVN? If not, that would be a good place to start for getting it >checked in. > > Thanks, > > Wayne > > -----Original Message----- > From: ssh...@us... [mailto:ssh...@us...] > Sent: Wednesday, January 05, 2011 4:25 PM > To: al...@us... > Cc: ssh...@us... > Subject: SandForce IOMeter integration > > Hi, > > My name is Shamil Sharief, the Technical Marketing > Specialist here at SandForce Inc. I believe one of my former > colleagues, Ben Englert, was in contact with the developers > of IOMeter, and I wanted to let you guys know that his torch > has been passed to me as of a bit ago. > > >From what I understand, the current status of SandForce's > input is at a non-existent phase. I was wondering if it > would be possible for me to work with you and whoever else I > need to be in touch with regarding incorporating our changes in. > > To recap, the change we've added is the ability to select > what file the tool uses as its data pattern. If it would be > possible for me to send you a copy of our source code, I > would appreciate it greatly. > > I've sent an identical message to Daniel Scheibli. If > someone could get back to me regarding this process needed > to get this going, it'd be great. Alternatively, maybe get > me in touch with who can help me with this? > > Thanks for all your help, > ~Shamil Sharief > > Technical Marketing Specialist > Direct: 408-864-0740 > Cell: 408-410-9527 > email: ssh...@sa... > > -- > This message has been sent to you, a registered SourceForge.net user, > by another site user, through the SourceForge.net site. This message > has been delivered to your SourceForge.net mail alias. You may reply > to this message using the "Reply" feature of your email client, or > using the messaging facility of SourceForge.net at: > https://sourceforge.net/sendmessage.php?touser=3187781 > > ------------------------------------------------------------------------------ > Learn how Oracle Real Application Clusters (RAC) One Node allows customers > to consolidate database storage, standardize their database environment, and, > should the need arise, upgrade to a full multi-node Oracle RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Iometer-devel mailing list > Iom...@li... > https://lists.sourceforge.net/lists/listinfo/iometer-devel > ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Iometer-devel mailing list Iom...@li... https://lists.sourceforge.net/lists/listinfo/iometer-devel |
|
From: ming z. <mi...@el...> - 2011-01-06 02:00:12
|
agree. a branch for this is better. On Wed, Jan 5, 2011 at 8:02 PM, Allen, Wayne <way...@in...> wrote: > Re-sending....ssh...@us... bounced. > > -Wayne > > -----Original Message----- > From: Allen, Wayne > Sent: Wednesday, January 05, 2011 5:00 PM > To: 'ssh...@us...'; iom...@li... > Subject: RE: SandForce IOMeter integration > > Hi Shamil, > > Yes, we had an email exchange with Ben toward the middle part of last year regarding some changes (though he described them a bit different than you). We communicated to him that we were working on finalizing a release and would be able to get to it after that. Our release didn't end up happening (due to all of our actual day jobs) till November. We are currently in a release-candidate state with that release, so the work isn't completely done yet. What I'd propose we do here (haven't run past the other admins) is that we create a branch for the features for our next release and can get your stuff in there. This also makes it available to folks across the industry if they want to pull source out of SVN and build it on their own prior to us releasing an official build. I'll let the other admins chime in if they have concerns with that. > > Could you explain your feature a bit more? Have you merged it with the latest trunk code in SVN? If not, that would be a good place to start for getting it checked in. > > Thanks, > > Wayne > > -----Original Message----- > From: ssh...@us... [mailto:ssh...@us...] > Sent: Wednesday, January 05, 2011 4:25 PM > To: al...@us... > Cc: ssh...@us... > Subject: SandForce IOMeter integration > > Hi, > > My name is Shamil Sharief, the Technical Marketing > Specialist here at SandForce Inc. I believe one of my former > colleagues, Ben Englert, was in contact with the developers > of IOMeter, and I wanted to let you guys know that his torch > has been passed to me as of a bit ago. > > >From what I understand, the current status of SandForce's > input is at a non-existent phase. I was wondering if it > would be possible for me to work with you and whoever else I > need to be in touch with regarding incorporating our changes in. > > To recap, the change we've added is the ability to select > what file the tool uses as its data pattern. If it would be > possible for me to send you a copy of our source code, I > would appreciate it greatly. > > I've sent an identical message to Daniel Scheibli. If > someone could get back to me regarding this process needed > to get this going, it'd be great. Alternatively, maybe get > me in touch with who can help me with this? > > Thanks for all your help, > ~Shamil Sharief > > Technical Marketing Specialist > Direct: 408-864-0740 > Cell: 408-410-9527 > email: ssh...@sa... > > -- > This message has been sent to you, a registered SourceForge.net user, > by another site user, through the SourceForge.net site. This message > has been delivered to your SourceForge.net mail alias. You may reply > to this message using the "Reply" feature of your email client, or > using the messaging facility of SourceForge.net at: > https://sourceforge.net/sendmessage.php?touser=3187781 > > ------------------------------------------------------------------------------ > Learn how Oracle Real Application Clusters (RAC) One Node allows customers > to consolidate database storage, standardize their database environment, and, > should the need arise, upgrade to a full multi-node Oracle RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Iometer-devel mailing list > Iom...@li... > https://lists.sourceforge.net/lists/listinfo/iometer-devel > |
|
From: Allen, W. <way...@in...> - 2011-01-06 01:03:03
|
Re-sending....ssh...@us... bounced. -Wayne -----Original Message----- From: Allen, Wayne Sent: Wednesday, January 05, 2011 5:00 PM To: 'ssh...@us...'; iom...@li... Subject: RE: SandForce IOMeter integration Hi Shamil, Yes, we had an email exchange with Ben toward the middle part of last year regarding some changes (though he described them a bit different than you). We communicated to him that we were working on finalizing a release and would be able to get to it after that. Our release didn't end up happening (due to all of our actual day jobs) till November. We are currently in a release-candidate state with that release, so the work isn't completely done yet. What I'd propose we do here (haven't run past the other admins) is that we create a branch for the features for our next release and can get your stuff in there. This also makes it available to folks across the industry if they want to pull source out of SVN and build it on their own prior to us releasing an official build. I'll let the other admins chime in if they have concerns with that. Could you explain your feature a bit more? Have you merged it with the latest trunk code in SVN? If not, that would be a good place to start for getting it checked in. Thanks, Wayne -----Original Message----- From: ssh...@us... [mailto:ssh...@us...] Sent: Wednesday, January 05, 2011 4:25 PM To: al...@us... Cc: ssh...@us... Subject: SandForce IOMeter integration Hi, My name is Shamil Sharief, the Technical Marketing Specialist here at SandForce Inc. I believe one of my former colleagues, Ben Englert, was in contact with the developers of IOMeter, and I wanted to let you guys know that his torch has been passed to me as of a bit ago. From what I understand, the current status of SandForce's input is at a non-existent phase. I was wondering if it would be possible for me to work with you and whoever else I need to be in touch with regarding incorporating our changes in. To recap, the change we've added is the ability to select what file the tool uses as its data pattern. If it would be possible for me to send you a copy of our source code, I would appreciate it greatly. I've sent an identical message to Daniel Scheibli. If someone could get back to me regarding this process needed to get this going, it'd be great. Alternatively, maybe get me in touch with who can help me with this? Thanks for all your help, ~Shamil Sharief Technical Marketing Specialist Direct: 408-864-0740 Cell: 408-410-9527 email: ssh...@sa... -- This message has been sent to you, a registered SourceForge.net user, by another site user, through the SourceForge.net site. This message has been delivered to your SourceForge.net mail alias. You may reply to this message using the "Reply" feature of your email client, or using the messaging facility of SourceForge.net at: https://sourceforge.net/sendmessage.php?touser=3187781 |
|
From: Allen, W. <way...@in...> - 2011-01-06 01:00:22
|
Hi Shamil, Yes, we had an email exchange with Ben toward the middle part of last year regarding some changes (though he described them a bit different than you). We communicated to him that we were working on finalizing a release and would be able to get to it after that. Our release didn't end up happening (due to all of our actual day jobs) till November. We are currently in a release-candidate state with that release, so the work isn't completely done yet. What I'd propose we do here (haven't run past the other admins) is that we create a branch for the features for our next release and can get your stuff in there. This also makes it available to folks across the industry if they want to pull source out of SVN and build it on their own prior to us releasing an official build. I'll let the other admins chime in if they have concerns with that. Could you explain your feature a bit more? Have you merged it with the latest trunk code in SVN? If not, that would be a good place to start for getting it checked in. Thanks, Wayne -----Original Message----- From: ssh...@us... [mailto:ssh...@us...] Sent: Wednesday, January 05, 2011 4:25 PM To: al...@us... Cc: ssh...@us... Subject: SandForce IOMeter integration Hi, My name is Shamil Sharief, the Technical Marketing Specialist here at SandForce Inc. I believe one of my former colleagues, Ben Englert, was in contact with the developers of IOMeter, and I wanted to let you guys know that his torch has been passed to me as of a bit ago. From what I understand, the current status of SandForce's input is at a non-existent phase. I was wondering if it would be possible for me to work with you and whoever else I need to be in touch with regarding incorporating our changes in. To recap, the change we've added is the ability to select what file the tool uses as its data pattern. If it would be possible for me to send you a copy of our source code, I would appreciate it greatly. I've sent an identical message to Daniel Scheibli. If someone could get back to me regarding this process needed to get this going, it'd be great. Alternatively, maybe get me in touch with who can help me with this? Thanks for all your help, ~Shamil Sharief Technical Marketing Specialist Direct: 408-864-0740 Cell: 408-410-9527 email: ssh...@sa... -- This message has been sent to you, a registered SourceForge.net user, by another site user, through the SourceForge.net site. This message has been delivered to your SourceForge.net mail alias. You may reply to this message using the "Reply" feature of your email client, or using the messaging facility of SourceForge.net at: https://sourceforge.net/sendmessage.php?touser=3187781 |
|
From: SourceForge.net <no...@so...> - 2010-12-21 20:32:41
|
Bugs item #3141400, was opened at 2010-12-21 13:32 Message generated for change (Tracker Item Submitted) made by jcagle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=427254&aid=3141400&group_id=40179 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Cagle (jcagle) Assigned to: Nobody/Anonymous (nobody) Summary: 1.1.0rc1 needs additional commas in CSV Initial Comment: Due to the addition of 3 columns to the output for MBps (decimal) results, the per-CPU processor utilization lines need 3 more commas output to make them line up with the same processor utilization numbers for the entire system. For example, change from this: PROCESSOR,CPU 0,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,1.359739,0.0052,1.359892,0,0,3125146,123.469213,,,,,,, to PROCESSOR,CPU 0,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,1.359739,0.0052,1.359892,0,0,3125146,123.469213,,,,,,, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=427254&aid=3141400&group_id=40179 |
|
From: SourceForge.net <no...@so...> - 2010-12-21 20:22:05
|
Bugs item #3141394, was opened at 2010-12-21 13:22 Message generated for change (Tracker Item Submitted) made by jcagle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=427254&aid=3141394&group_id=40179 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Cagle (jcagle) Assigned to: Nobody/Anonymous (nobody) Summary: 1.1.0rc1 won't reload ICF files Initial Comment: version 1.1.0 rc1 won't load ICF files that it has saved. It complains that the version isn't compatible or something. Changing the first line of the ICF file from "Version 1.1.0" to "Version 2006.07.27" seems to make it work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=427254&aid=3141394&group_id=40179 |
|
From: Allen, W. <way...@in...> - 2010-11-04 05:05:49
|
I’m personally not familiar with the specifics on the kernel changes. FIO issues asynchronous IOs (as far as what I’ve seen it do). To achieve queue depth with FIO, you’ll need to set it up with the # of threads to match the queue depth you are looking for. Best Regards, Wayne From: 노홍찬 [mailto:fal...@cs...] Sent: Wednesday, November 03, 2010 8:04 PM To: Allen, Wayne; iom...@li... Subject: RE: [Iometer-devel] A query for perfermance difference of asynchronous I/O between Linux and Window. Hi Wayne, Thank you very much for your kind reply. Can you specify the recent kernel problems not compatible with the current version of IOmeter in more detail, since in the first place I wanted to check the problems of asynchronous I/O in linux by using IOmeter benchmark. Is it the direct I/O or the native asynchronous I/O APIs? If the asynchronous I/O requests in FIO benchmark works fine, then I think I can use their method in programming an efficient asynchronous I/O module in Linux. Best Regards, Nate. From: Allen, Wayne [mailto:way...@in...] Sent: Thursday, November 04, 2010 1:16 AM To: 노홍찬; iom...@li... Subject: RE: [Iometer-devel] A query for perfermance difference of asynchronous I/O between Linux and Window. Hi Nate, There have been some kernel changes to Linux over the past few years that has made IOMeter not behave correctly on that OS with > QD1. We expect to resolve this in the next release of IOMeter. In the mean time you can use a tool called FIO to perform your Linux-based tests. Best Regards, Wayne From: 노홍찬 [mailto:fal...@cs...] Sent: Wednesday, November 03, 2010 3:28 AM To: iom...@li... Subject: [Iometer-devel] A query for perfermance difference of asynchronous I/O between Linux and Window. Dear all the developers, I recently tested several flash memory based SSDs (Intel x25-e, Intel x25-m, … ) by using IOmeter. In the same machine, I executed the most recent IOmeter to the same flash disk, using the same configuration as only random read requests on the basis of 4K I/O size. There was no big difference of IOPS performance between Linux (fedora 10) and Window (window server 8) when I set the number of outstanding I/O to 1. However, when I set the the number of outstanding I/O to a big number 32, then the IOPS number in window test result was almost 2 times of the IOPS number in linux test result. I used the same machine, the same storage device, and the same setting, but there was a big performance gap between the IOmeter test result in Window and in Linux. It was so strange to me, so I thought it’s because the asynchronous support of linux kernel might be much worse than that of window kernel. It will be very helpful, if you can give me an answer for this question. Why is the LINUX IOPS lower than the window IOPS in the same machine when the number of outstanding I/O is high? Best Regards Nate. |
|
From: 노홍찬 <fal...@cs...> - 2010-11-04 03:04:42
|
Hi Wayne, Thank you very much for your kind reply. Can you specify the recent kernel problems not compatible with the current version of IOmeter in more detail, since in the first place I wanted to check the problems of asynchronous I/O in linux by using IOmeter benchmark. Is it the direct I/O or the native asynchronous I/O APIs? If the asynchronous I/O requests in FIO benchmark works fine, then I think I can use their method in programming an efficient asynchronous I/O module in Linux. Best Regards, Nate. From: Allen, Wayne [mailto:way...@in...] Sent: Thursday, November 04, 2010 1:16 AM To: 노홍찬; iom...@li... Subject: RE: [Iometer-devel] A query for perfermance difference of asynchronous I/O between Linux and Window. Hi Nate, There have been some kernel changes to Linux over the past few years that has made IOMeter not behave correctly on that OS with > QD1. We expect to resolve this in the next release of IOMeter. In the mean time you can use a tool called FIO to perform your Linux-based tests. Best Regards, Wayne From: 노홍찬 [mailto:fal...@cs...] Sent: Wednesday, November 03, 2010 3:28 AM To: iom...@li... Subject: [Iometer-devel] A query for perfermance difference of asynchronous I/O between Linux and Window. Dear all the developers, I recently tested several flash memory based SSDs (Intel x25-e, Intel x25- m, … ) by using IOmeter. In the same machine, I executed the most recent IOmeter to the same flash disk, using the same configuration as only random read requests on the basis of 4K I/O size. There was no big difference of IOPS performance between Linux (fedora 10) and Window (window server 8) when I set the number of outstanding I/O to 1. However, when I set the the number of outstanding I/O to a big number 32, then the IOPS number in window test result was almost 2 times of the IOPS number in linux test result. I used the same machine, the same storage device, and the same setting, but there was a big performance gap between the IOmeter test result in Window and in Linux. It was so strange to me, so I thought it’s because the asynchronous support of linux kernel might be much worse than that of window kernel. It will be very helpful, if you can give me an answer for this question. Why is the LINUX IOPS lower than the window IOPS in the same machine when the number of outstanding I/O is high? Best Regards Nate. |
|
From: Allen, W. <way...@in...> - 2010-11-03 16:16:05
|
Hi Nate, There have been some kernel changes to Linux over the past few years that has made IOMeter not behave correctly on that OS with > QD1. We expect to resolve this in the next release of IOMeter. In the mean time you can use a tool called FIO to perform your Linux-based tests. Best Regards, Wayne From: 노홍찬 [mailto:fal...@cs...] Sent: Wednesday, November 03, 2010 3:28 AM To: iom...@li... Subject: [Iometer-devel] A query for perfermance difference of asynchronous I/O between Linux and Window. Dear all the developers, I recently tested several flash memory based SSDs (Intel x25-e, Intel x25-m, … ) by using IOmeter. In the same machine, I executed the most recent IOmeter to the same flash disk, using the same configuration as only random read requests on the basis of 4K I/O size. There was no big difference of IOPS performance between Linux (fedora 10) and Window (window server 8) when I set the number of outstanding I/O to 1. However, when I set the the number of outstanding I/O to a big number 32, then the IOPS number in window test result was almost 2 times of the IOPS number in linux test result. I used the same machine, the same storage device, and the same setting, but there was a big performance gap between the IOmeter test result in Window and in Linux. It was so strange to me, so I thought it’s because the asynchronous support of linux kernel might be much worse than that of window kernel. It will be very helpful, if you can give me an answer for this question. Why is the LINUX IOPS lower than the window IOPS in the same machine when the number of outstanding I/O is high? Best Regards Nate. |
|
From: 노홍찬 <fal...@cs...> - 2010-11-03 10:28:08
|
Dear all the developers, I recently tested several flash memory based SSDs (Intel x25-e, Intel x25- m, … ) by using IOmeter. In the same machine, I executed the most recent IOmeter to the same flash disk, using the same configuration as only random read requests on the basis of 4K I/O size. There was no big difference of IOPS performance between Linux (fedora 10) and Window (window server 8) when I set the number of outstanding I/O to 1. However, when I set the the number of outstanding I/O to a big number 32, then the IOPS number in window test result was almost 2 times of the IOPS number in linux test result. I used the same machine, the same storage device, and the same setting, but there was a big performance gap between the IOmeter test result in Window and in Linux. It was so strange to me, so I thought it’s because the asynchronous support of linux kernel might be much worse than that of window kernel. It will be very helpful, if you can give me an answer for this question. Why is the LINUX IOPS lower than the window IOPS in the same machine when the number of outstanding I/O is high? Best Regards Nate. |
|
From: Will M. <wjm...@gm...> - 2010-09-12 22:51:58
|
On 9/10/2010 10:56 PM, Vedran Degoricija wrote: > Hi Will, > These features have been considered and are on the TODO list. However, any help is > appreciated. > Iometer currently uses AIO. AFAIK, it should be the same AIO as FIO uses. However, > FIO has other interfaces such as the kernel IO one, and this is what Iometer > lacks. Do you have any experience with this? Sorry, no experience in that area yet. We will undoubtedly be taking a closer look at this and what it entails. > As for histograms, I had an exchange with some of the developers and saving off > all per-IO information might accure too much data and/or too much overhead for > high IOPS capable devices. There are other ways to do this in a way which will > have minimal impact to the system. This was one of my concerns, as a single run could easily run into the millions of IOPS. Our "solution" to that thus far would likely be to throw RAM at the system, but even that would accrue overhead. Were those exchanges here on the mailing list, and if so how far back? I'm all ears for low impact solutions, so if someone has a good idea I'm willing to look at implementing one. > Ved > > ---------------------------------------------------------------------------------- > *From:* Will Marone <wjm...@gm...> > *To:* iom...@li... > *Sent:* Thu, September 9, 2010 5:30:55 PM > *Subject:* [Iometer-devel] Access histograms and libaio > > All, > > A co-worker and I are looking to add a pair of features to IOMeter. Specifically, > we're looking at adding libaio support for Linux (similar to fio) and per-access > timestamps that could be used to generate a histogram. Right now we're at the > 1000m view of IOMeter as a whole, so some clarification on the questions: > > Currently, I understand that IOMeter uses "aio" for accesses, however I'm not sure > if that is the same "aio" that fio uses, or if it is a different one. If anyone > could clarify this, it would be greatly appreciated. > > As for the histogram, the current idea is (for the time being) to locally cache IO > timestamps for each IO request for a given run then dump to a disk on the machine > running dynamo, with the long term goal of reporting these back to the host and > including them in the regular reports. Is there any existing work in this area? > > Will > > ------------------------------------------------------------------------------ > Automate Storage Tiering Simply > Optimize IT performance and efficiency through flexible, powerful, > automated storage tiering capabilities. View this brief to learn how > you can reduce costs and improve performance. > http://p.sf.net/sfu/dell-sfdev2dev > _______________________________________________ > Iometer-devel mailing list > Iom...@li... <mailto:Iom...@li...> > https://lists.sourceforge.net/lists/listinfo/iometer-devel > |
|
From: Vedran D. <ve...@ya...> - 2010-09-11 05:57:00
|
Hi Will, These features have been considered and are on the TODO list. However, any help is appreciated. Iometer currently uses AIO. AFAIK, it should be the same AIO as FIO uses. However, FIO has other interfaces such as the kernel IO one, and this is what Iometer lacks. Do you have any experience with this? As for histograms, I had an exchange with some of the developers and saving off all per-IO information might accure too much data and/or too much overhead for high IOPS capable devices. There are other ways to do this in a way which will have minimal impact to the system. Ved ________________________________ From: Will Marone <wjm...@gm...> To: iom...@li... Sent: Thu, September 9, 2010 5:30:55 PM Subject: [Iometer-devel] Access histograms and libaio All, A co-worker and I are looking to add a pair of features to IOMeter. Specifically, we're looking at adding libaio support for Linux (similar to fio) and per-access timestamps that could be used to generate a histogram. Right now we're at the 1000m view of IOMeter as a whole, so some clarification on the questions: Currently, I understand that IOMeter uses "aio" for accesses, however I'm not sure if that is the same "aio" that fio uses, or if it is a different one. If anyone could clarify this, it would be greatly appreciated. As for the histogram, the current idea is (for the time being) to locally cache IO timestamps for each IO request for a given run then dump to a disk on the machine running dynamo, with the long term goal of reporting these back to the host and including them in the regular reports. Is there any existing work in this area? Will ------------------------------------------------------------------------------ Automate Storage Tiering Simply Optimize IT performance and efficiency through flexible, powerful, automated storage tiering capabilities. View this brief to learn how you can reduce costs and improve performance. http://p.sf.net/sfu/dell-sfdev2dev _______________________________________________ Iometer-devel mailing list Iom...@li... https://lists.sourceforge.net/lists/listinfo/iometer-devel |
|
From: Will M. <wjm...@gm...> - 2010-09-10 00:31:28
|
All, A co-worker and I are looking to add a pair of features to IOMeter. Specifically, we're looking at adding libaio support for Linux (similar to fio) and per-access timestamps that could be used to generate a histogram. Right now we're at the 1000m view of IOMeter as a whole, so some clarification on the questions: Currently, I understand that IOMeter uses "aio" for accesses, however I'm not sure if that is the same "aio" that fio uses, or if it is a different one. If anyone could clarify this, it would be greatly appreciated. As for the histogram, the current idea is (for the time being) to locally cache IO timestamps for each IO request for a given run then dump to a disk on the machine running dynamo, with the long term goal of reporting these back to the host and including them in the regular reports. Is there any existing work in this area? Will |
|
From: SourceForge.net <no...@so...> - 2010-09-07 14:42:00
|
Bugs item #3061235, was opened at 2010-09-07 10:41 Message generated for change (Tracker Item Submitted) made by zathri You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=427254&aid=3061235&group_id=40179 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Zathri (zathri) Assigned to: Nobody/Anonymous (nobody) Summary: Disk Targets Empty Initial Comment: I don't have any local Disk Targets listed. The computer is Windows 2008 R2, Adaptec 5405Z controller, IOmeter 2006.07.27 . How can have them listed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=427254&aid=3061235&group_id=40179 |
|
From: <is...@ya...> - 2010-08-16 20:17:14
|
Hi Wayne
This is neto from Brazil
How are you?
Thanks for your answer. Please count on me on the Iometer team to help and
contribute
All the best
neto
________________________________
From: "Allen, Wayne" <way...@in...>
To: "is...@ya..." <is...@ya...>; "iom...@li..."
<iom...@li...>; "iom...@li..."
<iom...@li...>
Sent: Mon, August 16, 2010 11:27:35 AM
Subject: RE: [Iometer-devel] Linux (dynamo) strange behavior: Strange
performance numbers and bad performance using reads
Hi Neto,
Since the original IOMeter Linux implementation there have been some Linux
kernel changes that have broken queued IO. You should be able to repro
non-queued performance fairly close between Windows and Linux (they will never
match exactly though). We have this on our list of feature enhancements to make
IOMeter compatible with the current Linux generation.
If you urgently need a solution for Linux, FIO is a tool that you could use.
Best Regards,
Wayne
From:is...@ya... [mailto:is...@ya...]
Sent: Sunday, August 15, 2010 6:49 PM
To: iom...@li...; iom...@li...
Subject: [Iometer-devel] Linux (dynamo) strange behavior: Strange performance
numbers and bad performance using reads
Hi All,
This is neto from Brazil
How are you?
First of All, I would like to thank you Joe, Ved and Daniel for all support and
help.
Now, my question is regarding: Linux (dynamo) behavior: Strange performance
numbers and bad performance using reads
I'm using latest Branch (but I already have had the same behavior with other
Iometer versions)
Windows - GUI
Linux - dynamo (Redhat 5.4 using dm-mp (multipathing) - Server with 64GB RAM.
Using FC (Fibre Channel) to connect to Storage Array.
Using writes (random writes) - performance is OK but the I/O numbers reported by
Iometer are not accurate. (Storage reports 500 IOPS and Iometer reports 200
IOPS)
Using reads (random reads) - performance is terrible. Using one worker or 50
workers the performance is the same. Increasing outstanding I/O doesn't help.
I have tried to recompile using O_DIRECT - same behavior.
Questions:
1) Why the numbers are not accurate?
2) Why do I have this "poor" performance on Linux (reads)? Writes are OK.
3) Outstanding I/O doesn't work on Linux. Why?
IMPORTANT: On Windows (dynamo) everything works as expected. :-)
Could you please help me to address those "questions"?
Thank you very much
All the best
neto
|
|
From: Allen, W. <way...@in...> - 2010-08-16 15:27:50
|
Hi Neto, Since the original IOMeter Linux implementation there have been some Linux kernel changes that have broken queued IO. You should be able to repro non-queued performance fairly close between Windows and Linux (they will never match exactly though). We have this on our list of feature enhancements to make IOMeter compatible with the current Linux generation. If you urgently need a solution for Linux, FIO is a tool that you could use. Best Regards, Wayne From: is...@ya... [mailto:is...@ya...] Sent: Sunday, August 15, 2010 6:49 PM To: iom...@li...; iom...@li... Subject: [Iometer-devel] Linux (dynamo) strange behavior: Strange performance numbers and bad performance using reads Hi All, This is neto from Brazil How are you? First of All, I would like to thank you Joe, Ved and Daniel for all support and help. Now, my question is regarding: Linux (dynamo) behavior: Strange performance numbers and bad performance using reads I'm using latest Branch (but I already have had the same behavior with other Iometer versions) Windows - GUI Linux - dynamo (Redhat 5.4 using dm-mp (multipathing) - Server with 64GB RAM. Using FC (Fibre Channel) to connect to Storage Array. Using writes (random writes) - performance is OK but the I/O numbers reported by Iometer are not accurate. (Storage reports 500 IOPS and Iometer reports 200 IOPS) Using reads (random reads) - performance is terrible. Using one worker or 50 workers the performance is the same. Increasing outstanding I/O doesn't help. I have tried to recompile using O_DIRECT - same behavior. Questions: 1) Why the numbers are not accurate? 2) Why do I have this "poor" performance on Linux (reads)? Writes are OK. 3) Outstanding I/O doesn't work on Linux. Why? IMPORTANT: On Windows (dynamo) everything works as expected. :-) Could you please help me to address those "questions"? Thank you very much All the best neto |
78 messages has been excluded from this view by a project administrator.
