SOLVED - Excessive Mathematica CPU usage on Solaris 10
Dave (from the UK)
am sending it to now. But the moderator has not approved it (despite other posts
being approved today), so I am sending it to just these two groups now.
I never have understood the logic for a message being held at 3 newsgroups when
only one is moderated.
</gripe>
If you don't use Mathematica 5.1 or 5.2 on Solaris 10, you might as well skip to
the next message, as this will not bother you.
I've reported on these newsgroups before that Mathematica 5.2 was using
excessive CPU time on Solaris 10. When the Mathematica GUI is used, computing
1+1 returns the answer 2 quite quickly, but then pegs the CPU usage at 100%
which will slow a system considerably.
Following a post of mine on comp.unix.solaris
the ever helpful Casper Dik at Sun Microsystems took an interest. After I run
some tests using the UNIX tools lsof, truss, prstat and others, Casper was able
to come up with a likely explanation and a workaround. When I implemented that
workaround, the problem went.
Sun have changed the default timeout of select() from 1 ms in Solaris 9 to 1 us
in Solaris 10. Mathematica was performing a task but on slower processors is
unable to complete it within 1 us, whereas it could do it in 1 ms under Solaris
9 with no problems. So it times out on Solaris 10 unless the CPU is quite fast
(how fast I don't know).
Casper feels this is a Solaris bug, and has submitted it as one:
"6404383 select() behavior changed in Solaris 10, breaking binary compatibility"
Casper Dik says he thinks Sun will round up the select timeout to 1ms again in
the library for select() - but his signature makes it clear he is speaking for
himself, not Sun!
The Sun Ultra 60, 80 & Blade 100 have all exhibited this problem and I would
expect it to be seen on the Ultra 1, 2, 5 and 10 too. Apparently a Sun Blade
1000 is not affected, but since I don't know the specs of the machine used, it
might mean slower Blade 1000's will be affected. I'm guessing, but perhaps
faster machines will be affected if they are more heavily loaded.
WORKAROUND
Hopefully Sun will release a patch at some point to address bug id 6404383, but
there is a workaround which prevents Mathematica pegging the CPU at 100%.
1) Download the C source code Casper wrote and save it as select_preload.c.
(For completeness I have stuck it at the end of this post, so all information is
is in the one post).
2) Compile the C source code 'select_preload.c' to make a
64-bit shared library.
cc -xtarget=ultra -xarch=v9 -G -Kpic select_preload.c -o select_preload.so
This syntax uses Sun's compiler (gcc will be different).
Note, that syntax is a bit different to what Casper posted on comp.unix.solaris
as I had to change it for the Mathematica kernel, which is a 64-bit binary.
3) Copy the shared library somewhere convenient - I used /usr/local/lib/
4) Edit the script that calls the Mathematica kernel. The script on the system
here is /usr/local/Wolfram/Mathematica/5.2/Executables/math, which I think is
the default.
These two lines:
LD_PRELOAD_64=/usr/local/lib/select_preload.so
export LD_PRELOAD_64
need to be added near the end of the script, just before the last line.
(Obviously, changing the LD_PRELOAD_64 line to point at wherever you have put
the shared library you built).
So the last 3 lines in the script
/usr/local/Wolfram/Mathematica/5.2/Executables/math are:
LD_PRELOAD_64=/usr/local/lib/select_preload.so
export LD_PRELOAD_64
exec "${MathKernel}" "$@"
5) Fire up Mathematica, compute 1+1 or something else silly, then look with
prstat. top or similar at CPU usage. Hopefully it will not keep climbing all the
time.
I hope that is useful to anyone affected. I have sent details to Wolfram since I
had created a support request.
Here is the C source Casper wrote, which addresses the issue. I've edited
his comment line on how to compile it, but other than that it is unchanged.
If there is any line wrapping of the C source, you might need to sort that out
manually.
/*
* Select roundup preload. (casper....@you.know.where)
* cc -G -Kpic select_preload.c -o select_preload.so
>> Note from David Kirkby - change to this for 64-bit:
>> cc -xtarget=ultra -xarch=v9 -G -Kpic select_preload.c -o select_preload.so
*/
#include <dlfcn.h>
#include <sys/time.h>
#define FUN_PROTO(type,internal,parms) \
type internal parms
#define DECLARE(type,name, parms) static FUN_PROTO(type,(*name), parms)
#define CAST(type, parms) (FUN_PROTO(type,(*), parms))
DECLARE(int,next_select,(int, fd_set *, fd_set *, fd_set *, struct timeval *));
#ifdef __GNUC__
void loadit(void) __attribute__ ((constructor));
#else
#pragma init(loadit)
#endif
void
loadit(void)
{
extern char **environ;
char **env;
int offset;
next_select = CAST(int, (int, fd_set *, fd_set *, fd_set *, struct timeval *
))dlsym(RTLD_NEXT, "select");
}
int select(int nfds, fd_set *restrict readfds, fd_set *restrict writefds,
fd_set *restrict errorfds, struct timeval *restrict timeout)
{
if (timeout != NULL && timeout->tv_sec == 0 && timeout->tv_usec > 0 &&
timeout->tv_usec < 1000)
timeout->tv_usec = 1000;
return (next_select(nfds, readfds, writefds, errorfds, timeout));
}
--
Dave K MCSE.
MCSE = Minefield Consultant and Solitaire Expert.
Please note my email address changes periodically to avoid spam.
It is always of the form: month-year@domain. Hitting reply will work
for a couple of months only. Later set it manually.
Casper H.S. Dik
>Sun have changed the default timeout of select() from 1 ms in Solaris 9 to 1 us
>in Solaris 10. Mathematica was performing a task but on slower processors is
>unable to complete it within 1 us, whereas it could do it in 1 ms under Solaris
>9 with no problems. So it times out on Solaris 10 unless the CPU is quite fast
>(how fast I don't know).
The precise technical explanation is that we changed the *minimum* timeout
from 1ms to 1us and we rounded up to the nearest ms; that is because the
underlying system call changed from a call which accepted millisecond
resolution to one which accepted nanoseconds.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Marc La Senne
You cannot imaging how it helps us
We had a similar issue with others products
Marc La Senne
Office Automation Unix
Amadeus S.A.S.
+33.(0)4.97.15.44.59
Casper H.S. Dik
>Thanks a lot
>You cannot imaging how it helps us
>We had a similar issue with others products
Could you tell us what other product this was?
Application can be fixed to workaround this by changing the
select() interval from { 0, 1} (tv_sec, tv_usec) to something
like {0, 1000} to match Solaris 9 behaviour.
Craig Carey
...
>Could you tell us what other product this was?
>
>Application can be fixed to workaround this by changing the
>select() interval from { 0, 1} (tv_sec, tv_usec) to something
>like {0, 1000} to match Solaris 9 behaviour.
>
A change like that would cause so very many programs to fail that
surely Sun mentioned the need to recompile or whatever.
|> Sun have changed the default timeout of select() from 1 ms in Solaris 9
|> to 1 us in Solaris 10. Mathematica was performing a task but on slower
(Maybe there is no "default" value, since no missing parameter).
The GNU C library the syntax happens to be this:
int select (int nfds, fd_set *read-fds, fd_set *write-fds,
fd_set *except-fds, struct timeval *timeout)
<< The select function blocks the calling process until there is
activity on any of the specified sets of file descriptors, or
until the timeout period has expired. >>
|> processors is unable to complete it within 1 us, whereas it could do it
|> in 1 ms under Solaris 9 with no problems. So it times out on Solaris 10
|> unless the CPU is quite fast (how fast I don't know).
|>
|> Casper feels this is a Solaris bug, and has submitted it as one:
|>
|> "6404383 select() behavior changed in Solaris 10, breaking binary
|> compatibility"
|>
|> Casper Dik says he thinks Sun will round up the select timeout to 1ms
|> again in the library for select() - but his signature makes it clear he
|> is speaking for himself, not Sun!
If Sun recompiles all their code inside of the company then customers
need to pay more. However in FreeBSD there is a file that can specify
the library used for each executable. Perhaps only about 1 line in a
hand created text file should be enough for a well designed OS.
-- Craig Carey
Dave (from the UK)
You only sent the message to sci.math.symbolic, not comp.unix.solaris too. I am
copying it there too - what you say is relevant to Solaris.
Craig Carey wrote:
> On 29 Mar 2006 14:16:32 GMT, Casper H.S. Dik <***@Sun.COM> wrote:
> ...
>
>>Could you tell us what other product this was?
>>
>>Application can be fixed to workaround this by changing the
>>select() interval from { 0, 1} (tv_sec, tv_usec) to something
>>like {0, 1000} to match Solaris 9 behaviour.
>>
>
>
> A change like that would cause so very many programs to fail that
> surely Sun mentioned the need to recompile or whatever.
Casper admits it is a bug.
> |> Sun have changed the default timeout of select() from 1 ms in Solaris 9
> |> to 1 us in Solaris 10. Mathematica was performing a task but on slower
>
> (Maybe there is no "default" value, since no missing parameter).
Casper Dik at Sun did correct me on the usage of "default". In case you did not
see his post, he said.
--quote from Casper Dik of Sun.--
> The precise technical explanation is that we changed
> the *minimum* timeout from 1ms to 1us and we
> rounded up to the nearest ms; that is because the
> underlying system call changed from a call
> which accepted millisecond resolution to one
> which accepted nanoseconds.
> Casper
> The GNU C library the syntax happens to be this:
>
> int select (int nfds, fd_set *read-fds, fd_set *write-fds,
> fd_set *except-fds, struct timeval *timeout)
>
> << The select function blocks the calling process until there is
> activity on any of the specified sets of file descriptors, or
> until the timeout period has expired. >>
>
> |> processors is unable to complete it within 1 us, whereas it could do it
> |> in 1 ms under Solaris 9 with no problems. So it times out on Solaris 10
> |> unless the CPU is quite fast (how fast I don't know).
> |>
> |> Casper feels this is a Solaris bug, and has submitted it as one:
> |>
> |> "6404383 select() behavior changed in Solaris 10, breaking binary
> |> compatibility"
> |>
> |> Casper Dik says he thinks Sun will round up the select timeout to 1ms
> |> again in the library for select() - but his signature makes it clear he
> |> is speaking for himself, not Sun!
>
> If Sun recompiles all their code inside of the company then customers
> need to pay more. However in FreeBSD there is a file that can specify
> the library used for each executable. Perhaps only about 1 line in a
> hand created text file should be enough for a well designed OS.
>
>
> -- Craig Carey
I think the point is that this is a bug and needs correcting - not a runtime
configurable parameter.
That said, it might just cause a problem if any developer develops code based on
the Solaris 10 value of 1 us, then finds when people patch their system, or
install a later release of Solaris, their code breaks because the timeout has
changed.
Casper H.S. Dik
>>>Application can be fixed to workaround this by changing the
>>>select() interval from { 0, 1} (tv_sec, tv_usec) to something
>>>like {0, 1000} to match Solaris 9 behaviour.
>>
>> A change like that would cause so very many programs to fail that
>> surely Sun mentioned the need to recompile or whatever.
>Casper admits it is a bug.
Dave's wording was somewhat imprecise, as he notes below. Technically,
the code is correct but historically, the "1us" timeout means something
different than "don't return within 1us". It was used to mean "don't
return before the next clock tick".
An application which doesn't want to check for a result every microsecond
should not have asked for it; you never know whether you'd get what you
want (what if you use an "asynchronous" kernel where all timeouts are
scheduled in a precise manner?)
But backward compatibility is sacred; and this includes many of the
unwritten rules which are codified into applications.
Dave (from the UK)
> "Dave (from the UK)" <see-my-s...@southminster-branch-line.org.uk> writes:
>
>
>>>>Application can be fixed to workaround this by changing the
>>>>select() interval from { 0, 1} (tv_sec, tv_usec) to something
>>>>like {0, 1000} to match Solaris 9 behaviour.
>>>
>>>A change like that would cause so very many programs to fail that
>>>surely Sun mentioned the need to recompile or whatever.
>
>
>>Casper admits it is a bug.
>
>
> Dave's wording was somewhat imprecise, as he notes below.
Sorry for the confusion caused.
All I need to do now is Solve the other CPU problem with Mathematica on Solaris
10 - see 'Another Mathematica CPU usage problem on Solaris 10!!'
Its a real shame some posts like these get "moderated away" if sent to
comp.soft-sys.math.mathematica. Surely a solution to a Mathematica problem
should go on a Mathematica newsgroup. But it failed to get past the moderator.
It seems I'm not the only one to find bug-releated posts get "moderated away"
(censored)
http://groups.google.co.uk/group/sci.math.symbolic/browse_frm/thread/1b9259e39b50a0/23a6a89f245fe587?lnk=st&q=censored+mathematica&rnum=1&hl=en#23a6a89f245fe587
http://groups.google.co.uk/group/sci.math.symbolic/browse_frm/thread/9fae21e870d5c0dc/328f6fc55316bafc?lnk=st&q=moderated+away+mathematica&rnum=2&hl=en#328f6fc55316bafc
http://groups.google.co.uk/group/sci.math.symbolic/browse_frm/thread/6b41952f7274abed/029997ed7bf48698?lnk=st&q=moderated+away+mathematica&rnum=1&hl=en#029997ed7bf48698
It's a shame I did not get more response when I tried to set up
comp.soft-sys.math.mathematica.unmoderated previously.
Richard L. Hamilton
> It seems I'm not the only one to find bug-releated posts get "moderated away"
> (censored)
Well, notwithstanding Solaris's commitment to backwards compatibility, it
sounds like the previous problem was in fact Mathematica's bug, insofar as
they asked for something other than what they actually wanted (i.e. a
reasonable delay, like 1000us, which is what asking for 1 got them before).
It sound and as if the code is written with the typical developer
arrogance that _their_ app is the one and only thing running on the system
that actually matters to the customer, and as if the arrogance of the
moderation policy is such that all problems _must_ be someone else's
fault.
If you're selling something, either you let yourself get slammed freely
(justified or not), and respond to it, or you get it that much worse later on.
Too bad they don't have some serious competition...they might change their
ways if they lost a bunch of customers.
--
mailto:rlh...@smart.net http://www.smart.net/~rlhamil
Lasik/PRK theme music:
"In the Hall of the Mountain King", from "Peer Gynt"
Dave (from the UK)
> In article <442f...@212.67.96.135>,
> "Dave (from the UK)" <see-my-s...@southminster-branch-line.org.uk> writes:
> [...]
>
>>It seems I'm not the only one to find bug-releated posts get "moderated away"
>>(censored)
>
> [...]
>
> Well, notwithstanding Solaris's commitment to backwards compatibility, it
> sounds like the previous problem was in fact Mathematica's bug, insofar as
> they asked for something other than what they actually wanted (i.e. a
> reasonable delay, like 1000us, which is what asking for 1 got them before).
I guess it depends on what the documentation says. But from a practical point of
view it is difficult to test code at timeouts less than what the software
presents you with. Sure, if you can set it to 1 us or 1 ms, you can test at 1
us, but if you can't test at 1 us (which I believe was the case in Solaris 9),
you really have no way of knowing.
Whilst the front end is very platform dependent, the kernel is apparently almost
platform independent. These CPU usage issues seem to be in the kernel, so one
might reason that Solaris 10 is presenting a problem that no other operating
system has.
> It sound and as if the code is written with the typical developer
> arrogance that _their_ app is the one and only thing running on the system
> that actually matters to the customer, and as if the arrogance of the
> moderation policy is such that all problems _must_ be someone else's
> fault.
I can't really comment on the code. It is pretty portable, running on quite a
few things. From experience I know that tends to reduce bugs, as what works on
one platform does not on another. I came unstuck when I run some code on a Cray,
where sizeof(short)==8. Running on various platforms tends to highlight bad
programming.
The comp.soft-sys.math.mathematica moderator is not a full time Wolfram Research
employee, but is actually Steve Christensen of Sunfreeware.
I think he does an excellent job on Sunfreeware, but I'm less happy about the
moderation on the comp.soft-sys.math.mathematica newsgroup. He has admitted to
earning some consultancy money from Wolfram and sells a product that relies on
Mathematica himself. So there is always reasons why one might think there is
bias. (J suspect he gets some money from Sun too, but good luck to him, as he
does on a good job on Sunfreeware. But it is rather ironic in this case, as it
is a Wolfram Research / Sun issue.)
> If you're selling something, either you let yourself get slammed freely
> (justified or not), and respond to it, or you get it that much worse later on.
Yes I agree. I don't think it helps to try to hide problems.
My guess is that there would be readers of comp.soft-sys.math.mathematica who
don't read comp.unix.solaris or sci.math.symbolic that could make a useful
contribution to this thread. Having access to more platforms to test on (dual
processor faster machines in particular) would be useful. The fact they don't
means a solution takes longer to arrive at. It is hard to see that being in
anyones interest.
But as I said before, I did seriously consider trying to set up
comp.soft-sys.math.mathematica.unmoderated, and had some agreement in principle
to idea from the body that decides on newsgroups. They said it was an unusual
request, but they would all it to be voted on.
But there was just insufficient interest. Of course, I was not allowed to ask
users on comp.soft-sys.math.mathematica about it - Steve would not post my
intentions on there.
When comp.soft-sys.math.mathematica was set up, there were large numbers of
Wolfram Research employees who voted for it. I could be pretty sure they would
all vote against an unmoderated group. So I think an attempt would fail.
</gripe>
Getting an alt.* newsgroup is a lot easier than a comp.*, but would be far less
useful.
> Too bad they don't have some serious competition...they might change their
> ways if they lost a bunch of customers.
They do from Maple.
There are a large number of computer algebra systems and to some they seem a
religion - worship one and hate another.
But there are not a lot of players in the high-end maths packages.
Wes W
>
> Too bad they don't have some serious competition...they might change their
> ways if they lost a bunch of customers.
>
And from Matlab (http://www.matlab.com) aside from Maple. Different
tools for different specialties, with tons of overlap.
Craig Carey
wrote:
>"Dave (from the UK)" <see-my-s...@southminster-branch-line.org.uk> writes:
>
>>>>Application can be fixed to workaround this by changing the
>>>>select() interval from { 0, 1} (tv_sec, tv_usec) to something
>>>>like {0, 1000} to match Solaris 9 behaviour.
>>>
There is C code and the binary & library from it. Did the fields of the
record get renamed by Sun, in their C code ?.
If time had of been measured with a real number instead of a record
(C struct) then maybe the failure of Mathematica resulted from a change
of the units of physical dimension (and doubtless not the
"resolution").
In Windows a program can start to seem defective if restarting every
2 seconds, and it is quite unclear Mathematica needs to poll 1000 times
every second (raised to 1 million). Pehaps Mathematica detects movement
of the mouse.
>But backward compatibility is sacred; and this includes many of the
>unwritten rules which are codified into applications.
>
Also I assume that Sun censors a little.
Let me write on a new hope for otherwise disadvantaged Sun customers,
the "System Architecture Council"
I didn't see a webpage on that but I am sure Mr Caspar Dik will
get out the names and webpages of the committees that have the desire
to stop standards deteriorating, eg. due to new bugs:
http://research.sun.com/people/mybio.php?c=571
A legal expert of a type, Ms Katie Dickinson has even got a US patent
patenting the idea of distributing software and then trying to verify
that it got unpackaged...
Here is text naming some of the review and appeal employee collectives
of Solaris's Mathematical base:
| SMI-wide processes which Katy has designed or managed include
| the SDF - Software Development Framework,
| SAC/ARC - System Architecture Council and
| Architecture Review Committees,
| TAC - Technology Architecture Council,
| TAB - Sun's external Technology Advisory Board,
| SEED - the Sun Engineering Enrichment & Development world-wide
| mentoring program,
| Archivist - Sun Labs' document archiving and clearance system, and
| the Global Product Engineering Cost Tool.
Competiting against a formal appeal to whomever it was that replaced
Ms Dickinson in the relevant committee, is that sacred principle.
Are the committees crippled in any significant way, Casper Dik ?.
The men of the leaked memo are no longer listed on Sun's people page;
and perhaps they got fired or constrained:
(1) Julian S. Taylor [he wrote it and the rest checked it]
(2) Steve Talley
(3) Mark Carlson
(4) Henry Knapp
(5) Willy (Waikwan) Hui
(6) Eugene Krivopaltsev
(7) Peter Madany
(8) Michael Boucher
The external Sun our-people page: http://research.sun.com/people/
Here is a copy of the visibly accessible leaked Sun memo:
http://www.internalmemos.com/memos/memodetails.php?memo_id=1321
http://www.archub.org/javamemo.txt [fixed width font]
Why is the name, Casper Dik, not on the 'people' webpage ?.
The title of it suggests that the list of employees is complete: the
title is:
"The People at Sun Labs/CTO"
When Mr Casper Dik suggested that something was sacred about
retaining binary compatibility across loadable libraries, does that
comment extend to the accountants or executives of Sun, or Ms Katie
Dickinson ?. Her name, too, is not on the people page. Perhaps
even managing a failing committee is a matter for fuller inquiry.
Perhaps Microsoft may have to shut down the Genuine Windows Advantage
browser plug in operation it has been running for too long....:
http://patft.uspto.gov/netacgi/nph-Parser?patentnumber=6,167,568
The people pages names Kati Dickinson and also Mr Chang:
Dickinson, Katy http://research.sun.com/people/mybio.php?c=571
Chang, Sheueling http://research.sun.com/people/mybio.php?c=604
| [Ms] Sheueling Chang [Sun Microsystems]
| Making security solutions stronger, faster, and -- this is very
| important -- [and] smaller [too].
...
| Until her team set to work three years ago, Chang says, "No one
| had the vision, courage, or persistence to bring elliptic curve
| technology to the forefront so it will have a broad impact on the
| Internet,
...
| Inspiration, perspiration -- and timing -- are key [ideas] to Chang.
...
>Casper
Craig Carey
>On 02 Apr 2006 10:12:02 GMT, Casper H.S. Dik wrote:
...
I made a mistake in that last message sent only to sci.math.symbolic.
>comment extend to the accountants or executives of Sun[?], or Ms Katie
>Dickinson ?. Her name, too, is not on the people page.
Actually Ms Dickinson's name was on the people page
...
>Dickinson, Katy http://research.sun.com/people/mybio.php?c=571
...
http://research.sun.com/people/ : (the people page)
Ms Katy Dickinson headed an archival system.
>| Archivist - Sun Labs' document archiving and clearance system, and
More evidence on the managment of paper records, eg. all the documents
produced by a Sun review committee examining the "sacred" binary level
backwards compatibility principle brought to sci.math.symbolic by Mr
Capser Dik, is here, at her blog website:
http://blogs.sun.com/roller/page/katysblog?catname=%2FChurch
...
| 20051205 Monday December 05, 2005
|
| Library, Service, Crafts Fair, Lessons & Carols, Christmas Tea
| Yesterday was back-to-back events and activities:
|
| * 9:30-10:30 a.m. Library. Worked with my daughter on the book
| catalogue data entry at the All Saints' Episcopal Church Library. We
| spent most of the $1000- we earned during our annual used book sale
| on buying 32 more Anchor Bibles from amazon.com and Christian Book
| Distributors. Before we unpack all the new books, we have been
| putting the rest of the almost-2000 book collection in order. This
| includes shifting books around [...]
...
More for blog readers: http://planetsun.org/filter/java/
Was there a cover up ?. It almost certain that Mathematica is badly
written: polling 1000 to get mouse packets is not needed since they
ought be arriving (complete with time stamps otherwise there are the
mouse deceleration ill-behaviour observed in Linux and FreeBSD).
Craig Carey
st...@smc.vnet.net
There have been some comments on and assumptions about
my rejection of the original posts to the Mathematica newsgroup
I moderate.
Those posts were not rejected as I never got them.
Further, I never reject a post unless I have first contacted
the author and discussed it. If you send something and it
does not show up within 24-48 hours at most, contact
me to make sure of the reason.
If my main address at steve (at) smc.vnet.net does not get
a message to me, try my other one at sunfreeware (at) gmail.com.
I am sorry there was a problem and am very interested in this
topic. I would ask that someone post a summary to
the Mathematica group.
I surely hope this will not happen in the future.
Steve Christensen
Dave (from the UK)
> I have just become aware of this thread in this newsgroup.
> There have been some comments on and assumptions about
> my rejection of the original posts to the Mathematica newsgroup
> I moderate.
>
> Those posts were not rejected as I never got them.
>
Well I did it. I think I have sent a couple on the topic at one point
which both went to /dev/null. Hence a later thread, where I realise the
solution was not 100%, did not bother to include
comp.soft-sys.math.mathematica.
In contrast I can't recall the last time a post was missed on an
unmoderated newsgroup.
> Further, I never reject a post unless I have first contacted
> the author and discussed it.
That does not seem to be the experience of myself or others. There are
plenty of reports of posts critical of Mathematica being censored.
This is not the first time at has happened to me either, which is why
tend to use another newsgroup.
> If you send something and it
> does not show up within 24-48 hours at most, contact
> me to make sure of the reason.
OK will do. But I must admit the I find the delay annoying, so it is
tempting to send it to another newsgroup or a forum instead.
I wonder if you have an issue at your end in this case? I assume the
process of posting is a bit different in the case of a moderated
newsgroup to one that is not.
Rather annoyingly (and I realise this is not your fault), posts sent to
any newsgroup that is not moderated get delayed if a moderated one (such
as comp.soft-sys.math.mathematica) is crossposted.
> If my main address at steve (at) smc.vnet.net does not get
> a message to me, try my other one at sunfreeware (at) gmail.com.
OK, will do if I decide to send other topics in the future. But having a
fairly high percentage of posts go to /dev/null does not make me feel
too happy about using comp.soft-sys.math.mathematica.again.
> I am sorry there was a problem and am very interested in this
> topic. I would ask that someone post a summary to
> the Mathematica group.
As I started the thread, I will post a summary to
comp.soft-sys.math.mathematica.. Perhaps I'll CC it to you, just to make
sure.
I did post a summary at one point (to comp.soft-sys.math.mathematica.
and comp.unix.solaris) but there have been developments since then, so
the summary could do with being changed a little.
> I surely hope this will not happen in the future.
Me too.
> Steve Christensen
All the best. I'll send you a summary at some point today.