Re: [OpenIndiana-discuss] ZFS remote receive
Message: 7 Date: Tue, 30 Oct 2012 22:03:13 +0400 From: Jim Klimovjimkli...@cos.ru To: Discussion list for OpenIndiana openindiana-discuss@openindiana.org Subject: Message-ID:50901661.9050...@cos.ru Content-Type: text/plain; charset=ISO-8859-1; format=flowed 2012-10-30 19:21, Sebastian Gabler wrote: Whereas that's relative: performance is still at a quite miserable 62 MB/s through a gigabit link. Apparently, my environment has room for improvement. Does your gigabit ethernet use Jumbo Frames (like 9000 or up to 16KB, depending on your NICs, switches and other networking gear) for unrouted (L2) storage links? It is said that traditional MTU=1500 has too many overheads with packet size and preamble delays between packets that effectively limit a gigabit to 700-800Mbps... //Jim -- The MTU is on 1500 on source and target system, and there are no fragmentations happening. On the target system I am seeing writes up to 160 MB/s with frequent zpool iostat probes. When iostat probes are up to 5s+, there is a steady stream of 62 MB/s. At this time I am not sure if that is indeed a networking issue. I am also not sure how jumbo frames could provide an intersting benefit here. The usually alleged 15% (which are already on the high side) are not in the scope of making or breaking the use case. BR Sebastian ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] ZFS remote receive
2012-10-31 13:58, Sebastian Gabler wrote: 2012-10-30 19:21, Sebastian Gabler wrote: Whereas that's relative: performance is still at a quite miserable 62 MB/s through a gigabit link. Apparently, my environment has room for improvement. Does your gigabit ethernet use Jumbo Frames (like 9000 or up to 16KB, depending on your NICs, switches and other networking gear) for unrouted (L2) storage links? It is said that traditional MTU=1500 has too many overheads with packet size and preamble delays between packets that effectively limit a gigabit to 700-800Mbps... The MTU is on 1500 on source and target system, and there are no fragmentations happening. The point of Jumbo frames (in unrouted L2 ethernet segments) is to remove many overheads - CSMA/CD delays being a large contributor - and send unfragmented chunks of 9-16Kb in size, increasing the local network efficiency. On the target system I am seeing writes up to 160 MB/s with frequent zpool iostat probes. When iostat probes are up to 5s+, there is a steady stream of 62 MB/s. I believe this *may* mean that your networking buffer receives data into memory (ZFS cache) at 62Mb/s, then every 5s the dirty cache is sent to disks during TXG commit at whatever speed in can burst (160Mb/s in your case). At this time I am not sure if that is indeed a networking issue. I am also not sure how jumbo frames could provide an intersting benefit here. The usually alleged 15% (which are already on the high side) are not in the scope of making or breaking the use case. Mostly elaborated above. Other ways to reduce networking lags were discussed by other responders, including use of netcat to pipe the stream quickly, ssh without encryption/with cheap encryption/with HPC patches. Based on some experience with NFS and OpenVPN I might also suggest to try UDP vs. TCP (i.e. with netcat), though this would probably play on the unsafe side - UDP-based programs include retries like NFS (or accept the drop of data like VoIP), as they deem necessary, and ZFS-send probably doesn't do this; it is rather fragile already. //Jim ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] SS cc multithread compilation switch (e.g., Parrot)
On 10/30/12 13:03, Udo Grabowski (IMK) wrote: I see sometimes people linking with -lpthread (do NOT use -pthread), without setting -mt for the Sun Studio compilers, see, e.g., the Parrot (OI 151a7) config: /usr/lib/parrot/3.6.0/tools/lib/Parrot/Config/Generated.pm This is wrong and should be corrected for all OI specs for multithreaded programs where this switch is missing, for the compile and the link steps. Both -lpthread and -lthread are unnecessary to create multithreaded applications on modern Solaris (i.e., Solaris 10, OpenSolaris, OpenIndiana and newer) because all of the interfaces have been folded into libc. All applications are multithreaded; the distinction was removed during S10 development. The days when there was a dummy error-returning pthread_create() in libc, and you could tell whether you were in a single-threaded environment by checking for that error are gone. Any place you were using those things, you may as well stop now. There is a nit regarding fork1() versus forkall() semantics, but if you need to know about that then you should definitely read the libpthread man page. And you should certainly use fork1() or forkall() in preference to just plain fork() in a modern application. The other thing -mt does is turn on _REENTRANT, which generally causes the header files to give you prototypes for the slightly unusual _r variants of the library functions with static data. (They're not always needed because most library functions defined with static data internally use thread-local variables and are mt-safe anyway.) But if you're already compiling successfully without _REENTRANT, then you probably don't need it. A lot of blood was spilled over the multi-threaded versus single-threaded distinction in the past, and it's a good thing that most of the distinction is now moot. Turn on -mt if you like, but I think you may be waving a dead chicken. -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] bad mutex crash?
Rich fixed the account for me (thanks Rich!) -Original Message- From: Jason Matthews [mailto:ja...@broken.net] Sent: Wednesday, October 31, 2012 5:01 AM To: 'Discussion list for OpenIndiana' Subject: Re: [OpenIndiana-discuss] bad mutex crash? I will take a shot in the dark here. I imagine the request will time out and be deleted in a few days. Then you could try again -- but I am just speculating. If Jesus was a web developer, that's how he would do it. j. -Original Message- From: Dan Swartzendruber [mailto:dswa...@druber.com] Sent: Tuesday, October 30, 2012 9:56 PM To: 'Discussion list for OpenIndiana' Subject: Re: [OpenIndiana-discuss] bad mutex crash? Wonderful fail on the illumos site. I went to the page to sign up to submit issues. When the activation mail arrived, somehow I deleted it by mistake. Guess what? Apparently there is no way to request a new one. I *can* click on the link to change my password, but that doesn't help because the account has not been activated, so I'm stuck. Fail 2 is the apparent lack of any email address (contact us) anywhere I can see on the top-level page. Seriously? I guess I will now create an email alias and a different user name and see if *that* works. Sigh... ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] ZFS remote receive
2012-10-30 19:21, Sebastian Gabler wrote: Whereas that's relative: performance is still at a quite miserable 62 MB/s through a gigabit link. Apparently, my environment has room for improvement. Does your gigabit ethernet use Jumbo Frames (like 9000 or up to 16KB, depending on your NICs, switches and other networking gear) for unrouted (L2) storage links? It is said that traditional MTU=1500 has too many overheads with packet size and preamble delays between packets that effectively limit a gigabit to 700-800Mbps... Erm… That's not true. IPv4 header is 20 bytes. TCP header the same, meaning 40 bytes in total out of 1500 bytes payload, leaving 1460 bytes left for real payload, or 97.3%. An overhead of 20-30% is *not* correct. The ~3% overhead matches well what I see in practice on my networks. You will get a gain with jumboframes, but mostly lower CPU use for handling the packets, and especially in iSCSI environments, but not much for the lower packet size overhead… Vennlige hilsener / Best regards roy -- Roy Sigurd Karlsbakk (+47) 98013356 r...@karlsbakk.net http://blogg.karlsbakk.net/ GPG Public key: http://karlsbakk.net/roysigurdkarlsbakk.pubkey.txt -- I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er et elementært imperativ for alle pedagoger å unngå eksessiv anvendelse av idiomer med xenotyp etymologi. I de fleste tilfeller eksisterer adekvate og relevante synonymer på norsk. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
[OpenIndiana-discuss] Gnome and the future
Hi all, as many people don't wanna see, gnome future is like a submarine without roof. So, my question. What about make the new gnome's fork as default desktop enviroment, just like is making linux mint. OI always have the step in the next time. That project look like very good with a lot of good toys... ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Gnome and the future
from what I remember of the conversations of the time, we cannot move to Gnome 3 because of certain Linux dependencies ... Gnome 2 is no longer changing, and no longer being patched ... We don't have time or resources to support a Gnome 2 desktop system development fork (at least I don't and I don't believe OI devs do either) and in fact most Illumos OS's don't include a graphical environment at all. Linux Mint (I believe) are actually looking to go to Gnome 3, but with a customised theme, they cannot afford to ignore GTK3, and sticking with GTK2 means that new projects will not work for them. Linux Mint's Gnome theme does not look like Gnome 2 ... Of course some (or even all) of my ramblings could be wrong. Jon On 30 October 2012 17:27, låzaro netad...@lex-sa.cu wrote: Hi all, as many people don't wanna see, gnome future is like a submarine without roof. So, my question. What about make the new gnome's fork as default desktop enviroment, just like is making linux mint. OI always have the step in the next time. That project look like very good with a lot of good toys... ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] SS cc multithread compilation switch (e.g., Parrot)
On 10/31/2012 9:49 AM, Udo Grabowski (IMK) wrote: Thanks a lot for this info, it's a pity that this isn't documented well, I also read the Multithread Guide http://docs.oracle.com/cd/E19253-01/816-5137/compile-74765/index.html and it's all not entirely complete nor completely consistent... confusing, at best. The bottom line here is that there are no dummy locks or other bugaboos hiding out in the modern system. Being threading-aware all of the time has simplified a lot of this grot. If you want, feel free to wave the -mt dead chicken around. Perhaps there's something deep and undocumented in the C++ compiler that it tweaks, if you're into that C++ scene. But the real locks and thread resources that were once located in libpthread and libthread are now actually in libc and are active all the time. Linking with them or failing to link with them doesn't change the behavior of locks or affect the presence of threads. If you look at the OpenIndiana source, you'll see that most of the code is compiled without -mt and simply sets -D_REENTRANT when desired to access the _r functions. (There are a few places using -mt, but there are many more where the code is MT-hot but doesn't use it. I suspect that the remaining -mt uses are just stale.) -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Gnome and the future
On Tue, Oct 30, 2012 at 5:27 PM, låzaro netad...@lex-sa.cu wrote: Hi all, as many people don't wanna see, gnome future is like a submarine without roof. So, my question. What about make the new gnome's fork as default desktop enviroment, just like is making linux mint. OI always have the step in the next time. That project look like very good with a lot of good toys... Creating a private fork of a major desktop environment seems like a huge amount of effort. Why not pick a different desktop? Personally, I like Xfce, it's actively maintained and does a pretty good job of being cross-platform, apart from being a decent environment in its own right. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Gnome and the future
On Tue, 30 Oct 2012 13:27:59 -0400, låzaro netad...@lex-sa.cu wrote: Hi all, as many people don't wanna see, gnome future is like a submarine without roof. So, my question. What about make the new gnome's fork as default desktop enviroment, just like is making linux mint. OI always have the step in the next time. That project look like very good with a lot of good toys... I suspect a lot of this decision is going to fall on whoever actually is willing to do the work to get it working and maintain it. I'm not there yet. That said, if there is going to be an overhaul of the DE, might I suggest Xfce for consideration? ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Gnome and the future
Date: Wed, 31 Oct 2012 13:35:02 + From: t12nsloo...@gmail.com To: openindiana-discuss@openindiana.org Subject: Re: [OpenIndiana-discuss] Gnome and the future from what I remember of the conversations of the time, we cannot move to Gnome 3 because of certain Linux dependencies ... Gnome 2 is no longer changing, and no longer being patched ... We don't have time or resources to support a Gnome 2 desktop system development fork (at least I don't and I don't believe OI devs do either) and in fact most Illumos OS's don't include a graphical environment at all. Linux Mint (I believe) are actually looking to go to Gnome 3, but with a customised theme, they cannot afford to ignore GTK3, and sticking with GTK2 means that new projects will not work for them. Linux Mint's Gnome theme does not look like Gnome 2 ... Of course some (or even all) of my ramblings could be wrong. Jon Mate is a fork of Gnome 2 that already has a community behind it. Mint features Mate as a key desktop choice. http://mate-desktop.org/ Perhaps that is what is being sought? Nathan ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Gnome and the future
Mate is a fork of Gnome 2 that already has a community behind it. Mint features Mate as a key desktop choice. http://mate-desktop.org/ except that Mate looks nothing like Gnome 2 ... so if the idea is to keep the look and feel of the current environment then Mate is not the way to go. We'd be better off going for XFCE, or another desktop Environment, not that I'm a fan of XFCE personally. Jon ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Gnome and the future
I am of a commercial view. I am interested in the most popular desktop and most developed environment which is accepted by the current or potential user base.It would not be the correct choice going with a project which either peters out or is not accepted by commercial users as this would waste development time and resource too? As an Enterprise system the commercial view should prevail? On 30/10/2012 17:27, låzaro wrote: Hi all, as many people don't wanna see, gnome future is like a submarine without roof. So, my question. What about make the new gnome's fork as default desktop enviroment, just like is making linux mint. OI always have the step in the next time. That project look like very good with a lot of good toys... ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss -- This transmission is intended to be private and confidential. Intended solely for the person or organisation to whom it is addressed. It may contain privileged and confidential information. If you are not the intended recipient, you should not copy, distribute or take any action in reliance on it. If you have received this transmission in error, please notify the sender at the e-mail address above. Thank you. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Gnome and the future
On Wed, 31 Oct 2012 15:25:13 +, openbabel openba...@gmail.com wrote: As an Enterprise system the commercial view should prevail? This is based on the false premise that OpenIndiana is an enterprise desktop operating system. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Gnome and the future
On Wed, Oct 31, 2012 at 11:25 AM, openbabel openba...@gmail.com wrote: I am of a commercial view. I am interested in the most popular desktop and most developed environment which is accepted by the current or potential user base.It would not be the correct choice going with a project which either peters out or is not accepted by commercial users as this would waste development time and resource too? As an Enterprise system the commercial view should prevail? My suggestion, as someone who spent an inordinate amount of time porting KDE 4.x to Solaris 10, go with something simple and easy. Once there's a working DE, folks can then choose to work/port other more complex DE's. Ben On 30/10/2012 17:27, låzaro wrote: Hi all, as many people don't wanna see, gnome future is like a submarine without roof. So, my question. What about make the new gnome's fork as default desktop enviroment, just like is making linux mint. OI always have the step in the next time. That project look like very good with a lot of good toys... ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Gnome and the future
On 1 November 2012 02:33, mag...@yonderway.com wrote: This is based on the false premise that OpenIndiana is an enterprise desktop operating system. +1. There are alot of very useful desktop operating systems already, so i see no point in OI trying to compete with them. In business speak OI has a sustainable competitive advantage with ZFS, zones, dtrace, etc etc and those alone are why most people will be attracted to OI. Our OI servers sit in various computer rooms and we talk to them exclusively over ssh, if it didn't feature a GUI we wouldn't notice or care. I wonder how many other OI users feel similarly? -- Kind regards, Jules golgy whats so wrong with plumb? hoolio nothing, in itself. it's just for me, knowing what it means infers i cannot any longer pretend to not be a complete square when it comes to computers Gryphon I don't know that knowing anything about plumb turns you into a nerd, but this conversation already has hoolio are you calling me nerdy? checkers hoolio: you know what initramfs means, AND does. You're lost to the non-geek world already Gryphon yes hoolio hrm hoolio goodbye cruel world. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Gnome and the future
So why OI has DE at all? Leading to your logic community has to cut off DE from distribution at all... And what we will have? Another one illumos based server distribution?! I see OI as OS for general purposes, so stopping development in DE will decrease value of OI. Yes, community is to small but we have to find compromise and community will grow up. P.S. I'm not an active OI developer, but I help with testing and I'm going to contribute as developer at future. - Maxim Julius Roberts wrote: On 1 November 2012 02:33, mag...@yonderway.com wrote: This is based on the false premise that OpenIndiana is an enterprise desktop operating system. +1. There are alot of very useful desktop operating systems already, so i see no point in OI trying to compete with them. In business speak OI has a sustainable competitive advantage with ZFS, zones, dtrace, etc etc and those alone are why most people will be attracted to OI. Our OI servers sit in various computer rooms and we talk to them exclusively over ssh, if it didn't feature a GUI we wouldn't notice or care. I wonder how many other OI users feel similarly? ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Gnome and the future
I never suggested stopping DE development. I merely suggested that thinking of OI as an enterprise desktop OS is trying to sell an idea that enterprises aren't going to buy. I'm actually going to switch from Mac to OI laptop after the holidays (getting crazier with age). Sent from my typewriter On Oct 31, 2012, at 6:48 PM, Maxim Kondratovich maxim@gmail.com wrote: So why OI has DE at all? Leading to your logic community has to cut off DE from distribution at all... And what we will have? Another one illumos based server distribution?! I see OI as OS for general purposes, so stopping development in DE will decrease value of OI. Yes, community is to small but we have to find compromise and community will grow up. P.S. I'm not an active OI developer, but I help with testing and I'm going to contribute as developer at future. - Maxim Julius Roberts wrote: On 1 November 2012 02:33, mag...@yonderway.com wrote: This is based on the false premise that OpenIndiana is an enterprise desktop operating system. +1. There are alot of very useful desktop operating systems already, so i see no point in OI trying to compete with them. In business speak OI has a sustainable competitive advantage with ZFS, zones, dtrace, etc etc and those alone are why most people will be attracted to OI. Our OI servers sit in various computer rooms and we talk to them exclusively over ssh, if it didn't feature a GUI we wouldn't notice or care. I wonder how many other OI users feel similarly? ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Gnome and the future
A GUI is only needed when you want to use the gui I see more benefit in better webmin-support for zfs, mysql and other serversoftware. Kind regards, The out-side Op 31 okt. 2012 om 23:30 heeft Julius Roberts hooliowobb...@gmail.com het volgende geschreven: On 1 November 2012 02:33, mag...@yonderway.com wrote: This is based on the false premise that OpenIndiana is an enterprise desktop operating system. +1. There are alot of very useful desktop operating systems already, so i see no point in OI trying to compete with them. In business speak OI has a sustainable competitive advantage with ZFS, zones, dtrace, etc etc and those alone are why most people will be attracted to OI. Our OI servers sit in various computer rooms and we talk to them exclusively over ssh, if it didn't feature a GUI we wouldn't notice or care. I wonder how many other OI users feel similarly? -- Kind regards, Jules golgy whats so wrong with plumb? hoolio nothing, in itself. it's just for me, knowing what it means infers i cannot any longer pretend to not be a complete square when it comes to computers Gryphon I don't know that knowing anything about plumb turns you into a nerd, but this conversation already has hoolio are you calling me nerdy? checkers hoolio: you know what initramfs means, AND does. You're lost to the non-geek world already Gryphon yes hoolio hrm hoolio goodbye cruel world. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Gnome and the future
On 1 November 2012 09:48, Maxim Kondratovich maxim@gmail.com wrote: So why OI has DE at all? Leading to your logic community has to cut off DE from distribution at all... And what we will have? Another one illumos based server distribution?! The community will do whatever the community wants :) I'm just saying i don't use OI for the GUI and i wonder how many people actually do. I see OI as OS for general purposes, so stopping development in DE will decrease value of OI. Yes, community is to small but we have to find compromise and community will grow up. I don't see OI as a general purpose OS, perhaps that's where our perspectives differ. -- Kind regards, Jules golgy whats so wrong with plumb? hoolio nothing, in itself. it's just for me, knowing what it means infers i cannot any longer pretend to not be a complete square when it comes to computers Gryphon I don't know that knowing anything about plumb turns you into a nerd, but this conversation already has hoolio are you calling me nerdy? checkers hoolio: you know what initramfs means, AND does. You're lost to the non-geek world already Gryphon yes hoolio hrm hoolio goodbye cruel world. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Gnome and the future
On Wed, 31 Oct 2012, mag...@yonderway.com wrote: On Wed, 31 Oct 2012 15:25:13 +, openbabel openba...@gmail.com wrote: As an Enterprise system the commercial view should prevail? This is based on the false premise that OpenIndiana is an enterprise desktop operating system. I would take more issue with the term commercial. OpenIndiana is based on an enterprise operating system, however, use as a desktop (for use with packaged software) is not commercially viable. The term commercially viable means that someone is willing to pay for the system with the intent of using it as a desktop. This does not mean that OpenIndiana can not offer a perfectly viable and useful desktop which is almost as performant and feature rich as popular desktops. OpenIndiana needs to offer a default desktop which is reliable and lightweight since it may be attached to a server or need to be used remotely. It should not require exotic GPU acceleration to be usable. By current standards Gnome2 is light-weight even though it used to be considered heavy-weight. KDE4 is pretty heavy. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Gnome and the future
webmin? Ick. Swapping a desktop gui for a web gui...still get a gui. So just offshore the gui problem eh? On Thursday, November 01, 2012 06:55 AM, Roel_D wrote: A GUI is only needed when you want to use the gui I see more benefit in better webmin-support for zfs, mysql and other serversoftware. Kind regards, The out-side ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Gnome and the future
On Thursday, November 01, 2012 03:01 AM, Ben Taylor wrote: On Wed, Oct 31, 2012 at 11:25 AM, openbabelopenba...@gmail.com wrote: I am of a commercial view. I am interested in the most popular desktop and most developed environment which is accepted by the current or potential user base.It would not be the correct choice going with a project which either peters out or is not accepted by commercial users as this would waste development time and resource too? As an Enterprise system the commercial view should prevail? My suggestion, as someone who spent an inordinate amount of time porting KDE 4.x to Solaris 10, go with something simple and easy. Once there's a working DE, folks can then choose to work/port other more complex DE's. What has the least dependencies? XFCE? KDE 3.5? Or forget DE and just get a window manager like WindowMaker? ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Gnome and the future
WindowMaker sounds good. Used it for a while a few years ago. Been thinking about looking at it again. :) -- Sent from my Jelly Bean Galaxy Nexus Christopher Chan christopher.c...@bradbury.edu.hk wrote: On Thursday, November 01, 2012 03:01 AM, Ben Taylor wrote: On Wed, Oct 31, 2012 at 11:25 AM, openbabelopenba...@gmail.com wrote: I am of a commercial view. I am interested in the most popular desktop and most developed environment which is accepted by the current or potential user base.It would not be the correct choice going with a project which either peters out or is not accepted by commercial users as this would waste development time and resource too? As an Enterprise system the commercial view should prevail? My suggestion, as someone who spent an inordinate amount of time porting KDE 4.x to Solaris 10, go with something simple and easy. Once there's a working DE, folks can then choose to work/port other more complex DE's. What has the least dependencies? XFCE? KDE 3.5? Or forget DE and just get a window manager like WindowMaker? ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Gnome and the future
I used WindowMaker for a couple years myself. It is an easy compile on *Solaris and works well. At least it compiled easy for me. I ultimately went back to OpenWindows. I own a large stock of Solaris 8 media, so I will never be without my OpenWindows packages. Jerry Kemp On 10/31/12 08:18 PM, Gregory S. Youngblood wrote: WindowMaker sounds good. Used it for a while a few years ago. Been thinking about looking at it again. :) -- Sent from my Jelly Bean Galaxy Nexus ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] ZFS remote receive
On Oct 31, 2012, at 5:53 AM, Roy Sigurd Karlsbakk r...@karlsbakk.net wrote: 2012-10-30 19:21, Sebastian Gabler wrote: Whereas that's relative: performance is still at a quite miserable 62 MB/s through a gigabit link. Apparently, my environment has room for improvement. Does your gigabit ethernet use Jumbo Frames (like 9000 or up to 16KB, depending on your NICs, switches and other networking gear) for unrouted (L2) storage links? It is said that traditional MTU=1500 has too many overheads with packet size and preamble delays between packets that effectively limit a gigabit to 700-800Mbps... Erm… That's not true. IPv4 header is 20 bytes. TCP header the same, meaning 40 bytes in total out of 1500 bytes payload, leaving 1460 bytes left for real payload, or 97.3%. An overhead of 20-30% is *not* correct. The ~3% overhead matches well what I see in practice on my networks. You will get a gain with jumboframes, but mostly lower CPU use for handling the packets, and especially in iSCSI environments, but not much for the lower packet size overhead… In the bad old days, you could get one interrupt per packet, but those days are long gone for high-speed NICs. Today, interrupt coalescing is quite common, further reducing the benefits of jumbo frames. NB, setting MTU to 9000 can actually work against performance when coalescing on some popular OSes. Ideally, the MTU should be set to what your workload needs and not more. Finally, a data point: using MTU of 1500 with ixgbe you can hit wire speed on a modern CPU. -- richard -- richard.ell...@richardelling.com +1-760-896-4422 ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] ZFS remote receive
On Oct 31, 2012, at 3:37 AM, Jim Klimov jimkli...@cos.ru wrote: 2012-10-31 13:58, Sebastian Gabler wrote: 2012-10-30 19:21, Sebastian Gabler wrote: Whereas that's relative: performance is still at a quite miserable 62 MB/s through a gigabit link. Apparently, my environment has room for improvement. Does your gigabit ethernet use Jumbo Frames (like 9000 or up to 16KB, depending on your NICs, switches and other networking gear) for unrouted (L2) storage links? It is said that traditional MTU=1500 has too many overheads with packet size and preamble delays between packets that effectively limit a gigabit to 700-800Mbps... The MTU is on 1500 on source and target system, and there are no fragmentations happening. The point of Jumbo frames (in unrouted L2 ethernet segments) is to remove many overheads - CSMA/CD delays being a large contributor - and send unfragmented chunks of 9-16Kb in size, increasing the local network efficiency. There is no CSMA/CD on gigabit and faster available from any vendor today. Everything today is switched. -- richard On the target system I am seeing writes up to 160 MB/s with frequent zpool iostat probes. When iostat probes are up to 5s+, there is a steady stream of 62 MB/s. I believe this *may* mean that your networking buffer receives data into memory (ZFS cache) at 62Mb/s, then every 5s the dirty cache is sent to disks during TXG commit at whatever speed in can burst (160Mb/s in your case). More likely: straight pipe send | receive is a blocking configuration. This is why most people who go for high speed send | receive use a buffer, such as mbuffer, to smooth out the performance. Check the archives, this has been rehashed hundreds of times on these aliases. -- richard -- richard.ell...@richardelling.com +1-760-896-4422 ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] ZFS remote receive
On Wed, Oct 31, 2012 at 8:44 PM, Richard Elling richard.ell...@richardelling.com wrote: On the target system I am seeing writes up to 160 MB/s with frequent zpool iostat probes. When iostat probes are up to 5s+, there is a steady stream of 62 MB/s. I believe this *may* mean that your networking buffer receives data into memory (ZFS cache) at 62Mb/s, then every 5s the dirty cache is sent to disks during TXG commit at whatever speed in can burst (160Mb/s in your case). More likely: straight pipe send | receive is a blocking configuration. This is why most people who go for high speed send | receive use a buffer, such as mbuffer, to smooth out the performance. Check the archives, this has been rehashed hundreds of times on these aliases. Thank you very much for rehashing it again, I stuck | mbuffer -b 8192 -m 256M -q 2 /dev/null | (some preliminary testing seemed to indicate it wanted 8192 blocksize for pipes, and when run from cron it produces an odd warning message) in the middle of my send | ssh recv pipe and was rewarded with this over gigabit ethernet: received 8.63GB stream in 89 seconds (99.3MB/sec) Previously I was getting 70MB/s or less, even after switching to arcfour128 for ssh cipher. My only gripe is that mbuffer doesn't have a manpage on OpenIndiana. Tim ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
